Subject: Characters with code >= 128 in the message body

From: [email-masked] (Serguei Miridonov)
Date: 3 Dec 1994 12:58:02 -0800

Hi!

Does anybody know if pine can be used to send/receive plain text
messages with characters above 128 in code table? When I type text with
these characters, pine always converts it into unreadable MIME format.
Everything is OK if such a message is delivered to recipient which is
also using pine or other mail reader with MIME capabilities. But there
are lot of people who don't even know about MIME or they don't use it by
some reason.

Actually I'm talking about users from Russia, Ukraine, etc. Many of them
have already experienced with such an unreadable mail. Is there any way
to avoid this incompatibility and to make pine to send plain text with
characters >= 128 ?

BTW there is standard de facto for Latin/Russian character set: koi8-r

Serguei Miridonov
Ensenada B.C., Mexico.

---

From: [email-masked] (Jim Davis)
Date: 3 Dec 1994 15:35:35 -0700

In article <[email-masked]>,
Serguei Miridonov <[email-masked]> wrote:
:
:Does anybody know if pine can be used to send/receive plain text
:messages with characters above 128 in code table?

You may think MIME encoding is a bother, and want to work around it,
but it may be your best chance to get 8-bit data intact in email from
Mexico to Russia.  I'd be surprised if you have an 8-bit-clean email
path between Mexico and Russia!  If you send 8-bit data over channels
that only can handle 7-bit data then your recipients won't see your
message intact.  MIME is a safe, standard way to send 8-bit data
across 7-bit email channels.

If you get a copy of the comp.mail.mime Frequently Asked Questions
file (available via anonymous ftp from
rtfm.mit.edu:/pub/usenet/comp.mail.mime, or check the comp.mail.mime
or news.answers newsgroups) then it will explain this in detail.  It
also will list the various MIME decoders besides Pine your recipients
could use.

---

From: [email-masked] (Barry Bouwsma)
Date: 6 Dec 1994 06:06:17 GMT

In a previous article, [email-masked] (Serguei Miridonov) says:

>I understand that sending 8-bit data in MIME
>format is more safe, but I also think that plain 8-bit text will be used
>in Russian e-mail for a long time. 

    Actually, MIME permits you to send 8-bit characters in one of three
possibilities -- BASE64, which would be useful where the majority of
the text is composed of non-ASCII characters, like Russian, or QUOTED-
PRINTABLE, which is usually used when only a few characters are non-ASCII,
as in German, French, and so on.  Pine3.91 uses both of these.

    There is a third possibility, which Pine3.92 will support, which is
8BIT, which actually sends 8-bit data, but only if Pine can guarantee from
the receiving MTA that the 8-bit data will not get lost.  At present only a
limited number of mailers support this 8BITMIME ESMTP capability (and
not all of them do perfectly, which will be the subject of an upcoming
message); however, I would guess that the number of mailers which do
support this will increase quite rapidly, since Eric Allman has made a
post to comp.mail.sendmail yesterday to outline the changes upcoming in
BSD Sendmail v8.7, which include 8BITMIME support.  I would guess that
Pine3.92 will be released about the same time, or shortly before, a
stable release of 8.7 appears, but that's only a guess.

>: I'd be surprised if you have an 8-bit-clean email
>: path between Mexico and Russia!
>
>OK! Surprise!!! I have an 8-bit-clean email path between Mexico and
>Russia! Why not? TCP/IP is 8-bit transparent and SMTP agents on my host
>and in Russia are 8-bit clean too. Moreover, even if some tcp/ip links
>are broken there are email relays in EUnet which are also 8-bit clean.

    The problem is not that a TCP/IP link would not be 8-bit clean, but
that some intermediate mailer, or the originating or receiving mailer,
would strip the data to 7 bits, or less likely, gag on the 8-bit data.

    Luckily, much e-mail can be sent directly from one machine to another,
or is handled by only one additional machine, making it quite possible
to send 8-bit data from one site to an obscure remote one and not have
the 8-bit data lost, giving the immediacy most of us have come to expect
of e-mail.

    While probably a majority of non-US sites might have 8-bit-clean MTAs
(the sendmail program which passes the mail from one machine to another),
there are still those which can be found which will lose your 8-bit data.
You may find a reasonably high occurrence of 8-bit-clean mailers outside
the US because of the need for people there to use 8-bit data in their
mail, and there are a good number of US sites which are 8-bit clean as well,
due to the widespread adoption of BSD sendmail v8.6.9, whose default
configuration is to pass 8-bit data.

>Anyway I think that it would be good
>idea to preserve any old standard in new programs.

    It may surprise you to learn that the only standard relating to mail
on the Internet specifically forbids sending anything beyond ASCII text.
Unfortunately, this standard was written way back when it was not felt
there would be a need to support anything beyond ASCII, and some machines
would not even handle octets of bits as bytes.  Unfortunately, because
this *is* the standard, everything must comply with it or an extension.
Thus, strictly speaking, these JustSend8 mailers are in violation of
RFC822.  If I could remember the number of the RFC which refers to the
8BITMIME ESMTP option, I'd refer you to it, but by using Pine3.92 and up
and an MTA which supports 8BITMIME, you will be able to send pure 8-bit
text with the guarantee it will not get stripped to 7 bits.

    My gut feeling is that those sites which have adopted JustSend8 MTAs
will quickly upgrade to 8BITMIME capable ones to take advantage of this.

    Remember that just because something is widely used does not make it
a standard.  You will not be able to send me 8-bit mail at the address
from which I post this, unless it arrives with MIME transport, so you
cannot say it is a standard to send 8-bit text.

    I can receive 8BITMIME mail at the address in the Reply-To: field.
I'll hold off on further discussion of this until I compose my post
concerning Pine3.92's 8BITMIME support.  PLEASE NOTE that Pine3.92 has
*NOT* been released yet so don't ask where to find it.

-- 
 Barry Bouwsma, back from Euro-bike-tour in Ann Arbor, Michigan
    Please direct mail to  <[email-masked]> (MIME-aware)
Unemployable System Crasher, seeking work with the Internet that will put me
somewhere near the Appenzell, Switzerland; have pivo and zmrzlina, will travel

---

From: Rahul Dhesi <[email-masked]>
Date: 6 Dec 1994 10:18:00 GMT

In <[email-masked]> [email-masked]

>...but I also think that plain 8-bit text will be used

>> I'd be surprised if you have an 8-bit-clean email
>> path between Mexico and Russia!

>Russia! 

Not surprising!   The Internet is a a fully connected network at the
session level -- any two nodes on the Internet can set up a direct
connection and they are guaranteed an 8-bit data path.  Only if some
other transport mechanism is involved (e.g., BITNET) is the 8-bit
data path not guaranteed.  So, to exchange email with 8-bit text,
only the two end nodes -- modulo any MX records on enemy sites --
need to understand 8-bit SMTP.

I went through this discussion before with some of users who wanted
the sendmail installed here to support 8-bit text.  They convinced me
that it should.  Why?  Because I came to understand that:

     If two end-users by mutual consent wish to break the standards
     without anybody else being affected, I should not come in their way.

So I reinstalled sendmail with the appropriate definitions, and they
were happy.  Nobody else noticed any difference.  I didn't notice
any difference.

In the case of a transport agent like sendmail, the pro-8-bit argument
has perhaps more merit than in the case of pine -- because it's hard to
bypass sendmail, but it's easy to bypass pine.  But I still think the
argument is worth hearing.  The ideal mail user agent will allow the
user to include 8-bit text, perhaps by having to explicitly request
this to avoid accidents.  This option is obviously for only those users
who make a deliberate decision to use 8-bit text.  But if two such
consenting adults both make this decision, the rest of us should not
come in their way.

Also, consider this:  A large fraction of Usenet news postings include
8-bit text.  They will not go away.  Any integration of News and mail
must allow for a few megabytes a day of incoming Usenet postings
containing 8-bit text.  So, one may as well take integration a tiny
step further and allow for outgoing postings and email messages
containing 8-bit text too.

This is emphatically not an either/or issue.  Encoding of 8-bit text is
a necessity when an executable binary is being transported, so it
should be supported.  But encoding of 8-bit text yields no benefit when
"consenting adults" are at the ends of a point-to-point link, and all
they want to do is read what the other person wrote, not execute it.
-- 
Rahul Dhesi <[email-masked]>
"At this point, you are babbling ignorantly." -- [email-masked] (Mark Crispin)

---

From: [email-masked] (Lea Viljanen)
Date: 7 Dec 1994 12:20:18 -0000

>they want to do is read what the other person wrote, not execute it.

Except it will be a pain in the nether region to fill various
mailertables etc with names of all the "consenting adult partners".
I suppose that's one of the reasons why the 8BITMIME-keyword(*) was 
invented in the ESMTP dialogue. So, why not do this the right way
and adopt the 8BITMIME-kayword?

(*) In this context 8BITMIME should probably read "I'm over 18".
-- 
Lea 'LadyBug' Viljanen        University of Helsinki      Lea doesn't
[email-masked]      Computing Centre            rhyme with tea.

---

From: Rahul Dhesi <[email-masked]>
Date: 7 Dec 1994 21:30:07 GMT

In <[email-masked]> [email-masked] (Lea

>mailertables etc with names of all the "consenting adult partners".

This was intended to be purely a user-driven feature.  If user A wishes
to include 8-bit text, he asks the mail agent to let him do so, and the
mail agent obliges.  Any table of "consenting adult partnetrs" is in
the user's head.  To protect naive users, the default action should of
course be to always encode 8-bit text.
-- 
Rahul Dhesi <[email-masked]>
"At this point, you are babbling ignorantly." -- [email-masked] (Mark Crispin)