Subject: Re: 400 lines. Pine3.91-8bit Patch, Sendmail8.7, 8bit turns into Quoted-Printable, Pine Q-P "bug".

From: [email-masked] (Per Hedeland)
Date: 21 Oct 1995 17:33:32 GMT

In article <[email-masked]> [email-masked] (SO Kwok Tsun) writes:
>Why sendmail not designed to decode QP to 8BIT when receiving a mail?

I believe Eric Allman looked into it during the alpha/beta test period
for sendmail 8.7, but found that it was a bit complicated and decided
not to delay the release further by implementation and testing of this
functionality. It may be included in a future version.

> Here in Hong Kong, we don't want to enable the QP flag of HP
>sendmail since our major receiver of 8-bit mail do have 8-bit capable
>sendmail mostly.

I don't know what version HP ships, but as far as 8.7.x (which can of
course be installed on HP-UX) is concerned:

If they announce their 8-bit capability through the 8BITMIME SMTP
extension (as sendmail 8.7 does), sendmail will not convert to Q-P. If
they don't, but are known to be 8-bit capable, you can tell sendmail not
to convert mail to them via the F=8 mailer flag (this should probably be
done per destination, e.g. using a mailertable or LOCAL_NET_CONFIG and
the 'smtp8' mailer). The first alternative is obviously more convenient.

--Per Hedeland
[email-masked]

---

From: Mark Crispin <[email-masked]>
Date: Sat, 21 Oct 1995 13:27:19 -0700

On 21 Oct 1995, SO Kwok Tsun wrote:
> SO Kwok Tsun [Ĭ��T]
> Information Technology Service Unit, CUHK
> [���䤤��j�Ǹ�T��ުA�ȳB]
> Email: [email-masked]

The above is an excellent example of why "just send 8-bits" is
wrong-headed.  I normally read netnews either in a window that displays
ISO-8859-1 or ISO-2022-JP.  The above text is in BIG5, the encoding used
in Taiwan and Hong Kong, and if I display it in a BIG5 xterm it will
display properly.  In an ISO-8859-1 window the results are, um,
interesting.

However, since it was just sent as 8-bits, Pine hasn't the slightest idea
what character set it is.  I suspect that Pine will innocently apply
quoted-printable to this message (which isn't bad by itself) but will
probably label it as ISO-8859-1.  Oops.  Not its fault, though.

If the posting had been labeled as being MIME CHARSET CN-BIG5, Pine would
at least have had some warning.

-- Mark --

DoD #0105, R90/6 pilot, FAX: (206) 685-4045  ICBM: N 47 39'35" W 122 18'39"
Science does not emerge from voting, party politics, or public debate.

---

From: Mark Crispin <[email-masked]>
Date: Sat, 21 Oct 1995 13:34:36 -0700

On Sat, 21 Oct 1995, Mark Crispin wrote:
> I suspect that Pine will innocently apply

No, it labelled it as US-ASCII, since I didn't have it configured for any
8bit character set.  US-ASCII with a bunch of undefined 8bit glyphs.
Well, I guess that's better than guessing at ISO-8859-1.

-- Mark --

---

From: Vladimir Solnicky Vladimír Solnický <[email-masked]>
Date: Mon, 23 Oct 1995 14:34:41 +0100 (MET)

On Sat, 21 Oct 1995, Terry Gray wrote:

> Having sendmail (or more likely, the delivery program, e.g. /bin/mail)
> do QP and Base64 decoding seems like a good idea to me, but I don't know
> of anyone who has done it.

  It can be done starting appropriate filters and changing the headers
from procmail (a simple example only for text/plain is in procmailex(1)). 
I use procmail as a delivery program, but it is not necessary. 

Regards, V. S.

|  |  Bc. Vladimir Solnicky (Vladimír Solnický using ISO 8859-1 or 2)
|  |  Institute of Information             UTIA AV CR
 \/   Theory and Automation                Pod vodarenskou vezi 4
Department of Computing Systems            182 08 Praha 8-Liben
+42 2 6605/2212   fax: +42 2 66414677      Czech Republic
+42 2 6605/2364   e-mail: [email-masked]   ftp.utia.cas.cz
http://www.utia.cas.cz/user_data/vs/vs-home-{en|cz|ce}.html

---

From: Leif Erlingsson <[email-masked]>
Date: Fri, 13 Oct 1995 17:14:55 +0100

Total length of this USENET News article = 170 lines + 230 lines = 400 lines.
The last 230 lines is a re-post of an older USENET News article.

Synopsis: Pine3.91-8bit Patch, Sendmail8.7, 8bit turns into Quoted-Printable,
	  or why 8bit properly labeled E-Mail's turns into Quoted-Printable.

	  Pine 3.91 features + bugs in SNMP Software & Local Delivery Agents
	  cause mail in Quoted-Printable format from Pine to be CUT.

	  Re-Post of E-Mail CUT TO 1/2.
	  Older USENET News Article posted in comp.mail.elm, mime,
	  sendmail posted maybe Oct 2 or Oct 3, Subject: E-Mail CUT TO 1/2.
	  posted maybe Oct 2 or Oct 3. Included below my .signature,
	  156 lines down!

Slogan:	  Avoid Quoted-Printable!

Keywords: sendmail 8.7, Mime, Pine, 8bit, Quoted-Printable, base64, Pine-8bit

Good News:
:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:
I was able to add two new features to Pine 3.91 that makes it possible
to send mail using  `Content-Transfer-Encoding: 8bit'  instead of
`Content-Transfer-Encoding: Quoted-Printable'  thanks to patches
supplied by Per Hedeland <[email-masked]>, and originally from
Ming-Yen Hsu <[email-masked]>:

Hi, following patch added two new features for Pine which can
be set from Setup in Pine and controlled from pinerc.

* enable-send-only-8bit         Send out 8 bit character with 8BIT
                                content-transfer-encoding instead of
                                QP or BASE64.
* enable-8bit-in-subject        Allow 8 bit editing in Subject field.

  These two features should be useful if you and recipient are both
using 8 bit clean MTAs, and the MUA is not MIME capable. Disable these
features if you find there were MTAs which will strip message into
7 bit.

  Hope this help before Pine 3.92 comes to real. :-) 

PS: The patch is also available by a email to [email-masked]
    with "Retrieve pine-for-8bit" in the Subject field.
:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:

Bad News:
:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:
Sendmail 8.7 can handle this well, but not previous Sendmail's, so when
sendmail 8.7 is used to send mail to non-8BITMIME machines without the new
F=8 mailer flag (see SENDMAIL RELEASE NOTES below), the default behaviour
is to convert labelled 8BITMIME input to 7BIT as required. This will happen
if the input is 8bit and properly labeled as 8bit (as it would be from the
patched Pine or exmh) and contains characters with the eighth bit set. What
happens then is that sendmail 8.7, using the code in mime.c, outputs the
8 bit body in 7 bit format, usually, if less than or exactly 1/8 of the
total characters have the eighth bit set, using Quoted-Printable.

If more than 1/8 of the total characters have the eighth bit set, mime.c
(sendmail 8.7) will use base64.

The  `well, not too bad'  news is that sendmail 8.7 can be configured to
let 8bit slip through unharmed even to non-8BITMIME machines using the
F=8 mailer flag in sendmail.cf. LET'S PRAY ALL SWEDISH SENDMAIL
ADMINISTRATORS DOES THIS!

                        SENDMAIL RELEASE NOTES
             @(#)RELEASE_NOTES  8.7 (Berkeley) 9/17/95

[..................]

        Eight-to-seven bit MIME conversions.  This borrows ideas from
                John Beck of Hewlett-Packard, who generously contributed
                their implementation to me, which I then didn't use (see
                mime.c for an explanation of why).  This adds the
                EightBitMode option (a.k.a. `8') and an F=8 mailer flag
                to control handling of 8-bit data.  These have to cope with
                two types of 8-bit data: unlabelled 8-bit data (that is,
                8-bit data that is entered without declaring it as 8-bit
                MIME -- technically this is illegal according to the
                specs) and labelled 8-bit data (that is, it was declared
                as 8BITMIME in the ESMTP session or by using the
                -B8BITMIME command line flag).  If the F=8 mailer flag is
                set then 8-bit data is sent to non-8BITMIME machines
                instead of converting to 7 bit (essentially using
                just-send-8 semantics).  The values for EightBitMode are:
                    m   convert unlabelled 8-bit input to 8BITMIME, and do
                        any necessary conversion of 8BITMIME to 7BIT
                        (essentially, the full MIME option).
                    p   pass unlabelled 8-bit input, but convert labelled
                        8BITMIME input to 7BIT as required (default).
                    s   strict adherence: reject unlabelled 8-bit input,
                        convert 8BITMIME to 7BIT as required.  The F=8
                        flag is ignored.
                Unlabelled 8-bit data is rejected in mode `s' regardless of
                        the setting of F=8.

:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:

Worse News (but old news):
:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:
According to RFC 1521 he Quoted-Printable encoding REQUIRES that encoded
lines be no more than 76 characters long. See below excerpt. BUT PINE 3.91
CONVERTS A LINE  EXACTLY 76 CHARACTERS LONG  AS IF IT WAS TOO LONG! This
can cause serious problems, if the line is a sentence ending with a `.' in
the 76'th and last position. Pine 3.91 will then move down the `.' to a
separate line, and put a `=' in position 76 on the original line.

Pine would be better off doing nothing with this line, but as it is, a new
line consisting of a single `.' is created.

This is BAAAAD, because there exist a lot of Local Delivery Agents, mis-
configured sendmail.cf's and old firewall software out there that will
CUT A MESSAGE AT THIS POINT! It is ***UNWISE*** to say the least, to send
an E-mail containing a line consisting of a single `.'.

Known culprits: Some different Delivery Agents used from the Mlocal line
in sendmail.cf, like HP-UX /bin/mail or some version(s) of "mail.local".
Suspected culprits: TIS Firewall Toolkit 'smapd' ("from what I can see in
the source-code, it calls sendmail without the '-oi'",
Per Hedeland <[email-masked]> writes.)

This is part of my motive for NOT WANTING the Quoted-Printable encoding,
but rather the 8bit. It is actually a combination of a MUA (Pine)
`Feature', and a number of bugs and misconfigurations on the Internet
that is the culprits.

ALSO SEE USENET News Article posted in comp.mail.elm, mime, sendmail
Subject: E-Mail CUT TO 1/2. Keywords: Local Delivery Agents, smapd, Pine, Quoted-Printable, ...
posted maybe Oct 2 or Oct 3. Included below my .signature

Borenstein & Freed                                          [Page 18-19]

RFC 1521                          MIME                    September 1993

      Rule #5 (Soft Line Breaks): The Quoted-Printable encoding REQUIRES
      that encoded lines be no more than 76 characters long. If longer
      lines are to be encoded with the Quoted-Printable encoding, 'soft'
      line breaks must be used. An equal sign as the last character on a
      encoded line indicates such a non-significant ('soft') line break
      in the encoded text. Thus if the "raw" form of the line is a
      single unencoded line that says:

          Now's the time for all folk to come to the aid of
          their country.

      This can be represented, in the Quoted-Printable encoding, as

          Now's the time =
          for all folk to come=
           to the aid of their country.

      This provides a mechanism with which long lines are encoded in
      such a way as to be restored by the user agent.  The 76 character
      limit does not count the trailing CRLF, but counts all other
      characters, including any equal signs.

:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:

/Leif Erlingsson, home:  			work:
Tel:    +46 8 604 0995  			Tel:	+46 8 764 8495
Fax:    +46 8 604 0995 (ask 1'st)		Fax:	+46 8  29 4975
E-mail:	[email-masked]	E-mail: [email-masked]

###########################################################################
######	USENET News Article	posted in ... comp.mail.elm, mime, sendmail
###########################################################################

Subject:
E-Mail CUT TO 1/2. Keywords: Local Delivery Agents, smapd, Pine, Quoted-Printable, ...

Keywords:
local Delivery Agents, Pine, Quoted-Printable, smapd, SMTP,
sendmail, MIME, mail.local, procmail, mail, rmail

Newsgroups:
comp.mail.elm (since Pine comes from elm), comp.mail.mime, comp.mail.sendmail

~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~
Synopsis:

This is an attempt to summarise problems uncovered in divers places and
programs used in E-mail delivery in connection with e.g. Quoted-Printable
coded E-Mail (e.g. from Pine) and other mail that may contain "." - lines.
It turns out that problems can arise in several places, depending on
operating system and sendmail distribution version and configuration.

~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~
Summary:

See above Synopsis. E-Mail can easily contain "." lines without the user
being aware of this. In several places along an E-Mails path to the
recipient, anything from the "." to the end of the message may be lost.
Quoted-Printable coding may produce "."-lines, where there was none before!
Known culprits:	Some different Delivery Agents used from the Mlocal line
in sendmail.cf, like HP-UX /bin/mail or some version(s) of "mail.local".
Suspected culprits: TIS Firewall Toolkit 'smapd' ("from what I can see in
the source-code, it calls sendmail without the '-oi'",
Per Hedeland <[email-masked]> writes, see below).

Now follows extracts from some interesting E-Mails, 1'st from Per Hedeland,
in translation from Swedish:

~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~
Per Hedeland <[email-masked]> wrote Mon Oct  2, in translation:
> 
> ... on both HP-UX 9 and Solaris 2 [/bin/mail and /bin/rmail] is the same
> program. Additionally, the HP-UX man-page says:
> 
>       When persons are named, mail takes the standard input up to an end-
>       of-file (or up to a line consisting of just a .) and adds it to each
>       person's mailfile.
> 
> But also (under WARNINGS):
> 
>       mail treats a line consisting solely of a dot (.) as the end of the
>       message, except when the rmail -d command is used.
> 
> (that also checks out if one tests it). So in HP-UX it's /bin/rmail that one
> should use in Mlocal, which HP's sendmail.cf also does, as well as the one
> generated by sendmail 8.7 - but not the one generated by 8.6 (though easily
> fixed in .mc, of course).
> 
> In Solaris [2] one has choosen another track:
> 
>             It reads from the standard input up to an end-of-file
>      (CTRL-D)  or,  if  reading  from a terminal device, until it
>      reads a line consisting of just a  period.
> 
> - so there it's OK with /bin/mail in Mlocal. To increase the confusion, in
> SunOS 4 (where the man-page is found under 'binmail', 'mail' is ucbmail)
> it says:
> 
>      When addresses are named, /usr/bin/mail takes  the  standard
>      input  up  to an EOF (or a line with just `.') and routes it
>      through the mailer daemon  to  each  recipient.
> 
> - even though it isn't any problem with using /bin/mail in Mlocal. I don't
> know what makes it disregard the '.', perhaps it's the '-d' that sendmail
> supplies (and which isn't even in the man-page) - without the -d 
> mails are cut [that contains single "." line(s)], but if this depends on
> /bin/mail itself does it or because it gives the letter to sendmail without
> -oi is a little difficult to figure out.
> 
> But none of this explains why your *outgoing* mails (from RSV, see below)
> to me [Per Hedeland <[email-masked]>] are cut - I first figured that
> uucp was involved since it says 'from uucp@localhost' in one of the
> Received:-lines, but it doesn't seem to be so. Rather, it seems to be
> your 'smapd' that executes as user 'uucp'. That is of course no problem
> in itself, but I actually believe that smapd is the culprit there - from
> what I can see in the source-code, it calls sendmail without the '-oi'.
> 
> The bottom line is perhaps that You were right in Your News-article after
> all, lonely dots can cause problems in many places, if not really in SMTP -
> and a good Quoted-Printable-coder should make sure that they are not
> generated (or even let through uncoded - at least that would make the
> stupid thing useful for something :-).
> 
> ...
[Per also quoted a test-line containing a single "." sent from swip.net
to him, to show that he received mail from swip.net / swipnet.se correct
(as opposed from rsv.svskt.se).]

~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~
Keith Moore says Sat, 30 Sep:
> 
> Leif Erlingsson says Fri, 29 Sep, in comp.mail.mime, comp.mail.elm:
> >
> > We can't expect all old mailers to be correctly configured! E-Mail can
> > take many-a-strange route to it's destination. We must not count on
> > everything being correctly configured!
> 
> What you're really saying is:
> 
> 	We can't expect mailers to implement SMTP properly!
> 
> I don't buy it.  SMTP's dot quoting algorithm takes about two lines
> of C code to implement. It's difficult to imagine a framing protocol 
> that would be simpler.  Use of the dot quoting algorithm in SMTP is NOT 
> optional, and there's no reason that an implementation should be 
> dependent on having a particular option flag set before it will work. 
> 
> > I say that Pine/MIME ought to be patched so a single "." NEVER appears
> > alone on a line! Perhaps by rather cutting the line a little earlier to
> > prevent this from happening.
> 
> I see nothing wrong with avoiding "." at the beginning of a line when
> generating quoted-printable.  But the fact is that this is an MTA 
> problem, not a problem with Pine or MIME.
> 
> Keith
> 

Keith is of course right, that it's a MTA problem. But my philosophy is
to try to avoid potential problems wherever possible while hoping (and
working) for a better world!

~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~
Patrik Faltstrom <[email-masked]> wrote Sat, 30 Sep:
> 
> At 06.22 95-09-29, Leif Erlingsson wrote:
> >We can't expect all old mailers to be correctly configured! E-Mail can take
> >many-a-strange route to it's destination. We must not count on everything
> >being correctly configured!
> 
> Wait a minute...by having a misconfigured mail configuration anything
> can happen with your email. You can not say that we have to find
> a solution that works with any misconfigured email system in the world.
> 
> The problem with the hidden dot algorithm is not, to my knowledge,
> that it is the smtp delivery agent that is misconfigured, but where
> you have added your own delivery agents, such as emil, mail.local
> or just anything. Depending on if those agents do use the hidden-dot
> alogrithm or not, you have to add the X flag. You have the same
> problem with some other flags, such as the flag u, which is
> needed sometimes.
> 
> IF the mailer is using the hidden dot algorithm (just in case) and the
> receiver is not (i.e. mail.local is not) then you will end up having
> two dots in your mail, and not one.
> 
> Your proposal of forcing pine to use the hidden-dot algorithm only

I never proposed this! I simply proposed to avoid single dot-lines, by
always moving down a little more than the trailing "." from a line that
was considered too long (or why not avoid moving it altogether!).
								/Leif
> works if your mail happen to pass one mailer which uses the
> algorithm, but you can not know if that is the case.
> 
>    Patrik
> 

~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~
Patrik Faltstrom <[email-masked]> wrote Mon Oct  2, in translation:
> 
> At 06.22 95-09-29, Leif Erlingsson wrote:
> >We can't expect all old mailers to be correctly configured! E-Mail can
> >take many-a-strange route to it's destination. We must not count on
> >everything being correctly configured!
> 
> I just want to add that I see that You have an account with
> mailbox.swip.net and that I discovered last week that they use a
> broken mail.local, that is, it cuts letters at lonely dots, but if
> there's two dots, none is removed.
> 
> That is to say, the problems you have experienced may not be caused by
> problems when the letters ENTER the mailsystem, but when they shall
> EXIT it, down to Your mailbox.
> 
> I've discussed this with Uffe at swipnet and I hope that the whole
> issue can be solved as fast as possible.
> 
>    Patrik
> 

Patrik is partly right. *MOST* of my problems is caused by local
delivery agents. But not all. My initial problem mail

*FROM*	Leif Erlingsson	<[email-masked]>
*TO*	Per Hedeland	<[email-masked]>

didn't fail for this reason. I managed to send identical mails

*FROM*	Leif Erlingsson	<[email-masked]>
*TO*	Per Hedeland	<[email-masked]>

without any problems at all!	Check out the letter from near the
top of this very long E-mail. Search for the word 'smapd'!

~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~
Uffe Vedenbrant says Sun, 01 Oct in translation:
> 
> > That is to say, the problems you have experienced may not be caused by
> > problems when the letters ENTER the mailsystem, but when they shall
> > EXIT it, down to Your mailbox.
> 
> The program for local delivery, "mail.local", behaved a little funny,
> like Patrik says. A new one picked from the latest sendmail distribution
> seems to have solved the problem.
> 
> Thanks for the remark.
> 
> /Uffe
> 

~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~

/Leif Erlingsson, home:  			work:
Tel:    +46 8 604 0995  			Tel:	+46 8 764 8495
Fax:    +46 8 604 0995 (ask 1'st)		Fax:	+46 8  29 4975
E-mail:	[email-masked]	E-mail: [email-masked]

I advocate procmail as local Delivery Agent!

---

From: [email-masked] (Per Hedeland)
Date: 15 Oct 1995 12:01:37 GMT

In article <Pine.LNX.3.91.951013150054.661B-100000@localhost> Leif Erlingsson <[email-masked]> writes:
>is to convert labelled 8BITMIME input to 7BIT as required.

This is not "Bad News", but a *feature* (no smiley), the most important
one in 8.7 in my personal opinion. It will finally allow us to use 8-bit
characters in a standards-compliant way, without resorting to Quoted-
Printable, among those who announce their capability to do so - i.e.
*without* sending 8-bit characters to other systems, that may bit-strip
or even flat out refuse to accept them (there are systems of both
varietes out there, and they're all perfectly within their rights to do
what they do).

>ADMINISTRATORS DOES THIS!

Let's *not* - the F=8 flag is intented for use in local environments,
where not all of your MTA's may be upgraded to announce 8BITMIME, but
you nevertheless are sure (by means of some out-of-bands information/
agreement/directive) that they are capable of handling 8-bit mail.

I.e. it should never be used for a mailer that sends to the Internet in
general (and even *.se is "general" in this respect) - it is of course
possible to use it for specific destinations with whom you have
agreements to that effect, if you are prepared to accept the
administrative burden of keeping track of this. A simpler solution is of
course to suggest to those that are bothered by receiving Q-P that they
upgrade to an MTA that is capable of announcing 8BITMIME support - such
as sendmail 8.7.x.

--Per Hedeland
[email-masked]

---

From: [email-masked] (SO Kwok Tsun)
Date: 21 Oct 1995 07:18:48 GMT

>upgrade to an MTA that is capable of announcing 8BITMIME support - such

Why sendmail not designed to decode QP to 8BIT when receiving a mail? If
this problem can be solved, mail can often stored as as-is and many
existing MUA can read 8-bit messages. I think the transition can be
smoother. Here in Hong Kong, we don't want to enable the QP flag of HP
sendmail since our major receiver of 8-bit mail do have 8-bit capable
sendmail mostly.

--
SO Kwok Tsun [Ĭ��T]

---

From: Terry Gray <[email-masked]>
Date: Sat, 21 Oct 1995 08:38:48 -0700 (PDT)

-teg

On 21 Oct 1995, SO Kwok Tsun wrote:

> SO Kwok Tsun [Ä¬°ê«T]
> [»´ä¤¤¤å¤j¾Ç¸ê°T¬ì§ÞªA°È³B]
> Email: [email-masked]
>

---

From: [email-masked] (Kari E. Hurtta)
Date: 21 Oct 1995 14:52:59 GMT

[email-masked] (SO Kwok Tsun) writes:
»[email-masked] (Per Hedeland) writes:

»>I.e. it should never be used for a mailer that sends to the Internet in
»>general (and even *.se is "general" in this respect) - it is of course
»>possible to use it for specific destinations with whom you have
»>agreements to that effect, if you are prepared to accept the
»>administrative burden of keeping track of this. A simpler solution is of
»>course to suggest to those that are bothered by receiving Q-P that they
»>upgrade to an MTA that is capable of announcing 8BITMIME support - such
»>as sendmail 8.7.x.

»Why sendmail not designed to decode QP to 8BIT when receiving a mail? If

Perhaps lack of time? (In code of sendmail 8.7 there is flag for that
with comment "not implemented"):

7TO8 (not implemtented):
conf.h:119:# ifndef MIME7TO8
conf.h:120:#  define MIME7TO8	1	/* 7->8 bit MIME conversions */
sendmail.h:368:#define MCIF_CVT7TO8	0x2000		/* convert from 7 to 8 bits */
8TO7 (implemented):
conf.c:219:#if MIME8TO7
conf.c:3597:#if MIME8TO7
conf.c:3598:	"MIME8TO7",
conf.h:115:# ifndef MIME8TO7
conf.h:116:#  define MIME8TO7	1	/* 8->7 bit MIME conversions */
deliver.c:1531:		mci->mci_flags |= MCIF_CVT8TO7;
deliver.c:1533:		mci->mci_flags &= ~MCIF_CVT8TO7;
deliver.c:2396:#if MIME8TO7
deliver.c:2397:	if (bitset(MCIF_CVT8TO7, mci->mci_flags))
headers.c:1140:		    bitset(MCIF_CVT8TO7|MCIF_INMIME, mci->mci_flags))
headers.c:1236:#if MIME8TO7
headers.c:1241:	    !bitset(MCIF_CVT8TO7, mci->mci_flags))
mime.c:59:#if MIME8TO7
mime.c:76:**  MIME8TO7 -- output 8 bit body in 7 bit format
readcf.c:1345:#if MIME8TO7
readcf.c:1592:#if MIME8TO7
sendmail.h:365:#define MCIF_CVT8TO7	0x0400		/* convert from 8 to 7 bits */
srvrsmtp.c:348:#if MIME8TO7
usersmtp.c:370:#if MIME8TO7
usersmtp.c:377:		mci->mci_flags |= MCIF_CVT8TO7;

»this problem can be solved, mail can often stored as as-is and many
»existing MUA can read 8-bit messages. I think the transition can be
»smoother. Here in Hong Kong, we don't want to enable the QP flag of HP
»sendmail since our major receiver of 8-bit mail do have 8-bit capable
»sendmail mostly.

---

From: Rahul Dhesi <[email-masked]>
Date: 21 Oct 1995 22:46:06 GMT

In <loo-ong-message-id> Mark Crispin <[email-masked]> writes:

>> [=AD=BB=B4=E4=A4=A4=A4=E5=A4j=BE=C7=B8=EA=B0T=AC=EC=A7=DE=AAA=B0=C8=B3B]

>wrong-headed....Pine hasn't the slightest idea
>what character set it is.

The "just send 8 bits" philosophy is for use "between consenting
adults", so to speak.  When sender and recipient have prior agreement
about the character set being used, "just send 8 bits" is not only
acceptable, but also the most efficient and simple protocol.

The "just send 8 bits" strategy works just fine for email, since it's
always sent to a specific recipient.  It can work for Usenet News in
regional newsgroups, but is of course undesirable in Newsgroups with
global scope.

Clearly, misapplications can occur.  The "wrong-headed" label belongs
to a specific application of "just send 8 bits", not to the basic
strategy itself.

On the other hand, traditionally people have put pretty much anything
they wanted in their .signature.  So, "just send 8 bits" in the
.signature part of a Usenet posting should be happily tolerated - it's
not very different from some obscure quote or a puzzling ascii graphic.
-- 
Rahul Dhesi <[email-masked]>
"please ignore Dhesi" -- Mark Crispin <[email-masked]>

---

From: [email-masked] (Mr. Chow Wing Siu)
Date: 22 Oct 1995 09:23:39 GMT

As a BIG5 user, I quite agree that pine seems to ignore 8 bit news sending
problem.  Even I turn to ISO-8859-1 and all relevant environmental variables 
to accept 8 bit.  Although I think tin is better than pine as a news program,
it is better to have any patch to fix this minor problem. 

TIA.

--
Johnson Chow

Mark Crispin ([email-masked]) wrote:
: On 21 Oct 1995, SO Kwok Tsun wrote:
: > SO Kwok Tsun [=C4=AC=B0=EA=ABT]
: > Information Technology Service Unit, CUHK
: > [=AD=BB=B4=E4=A4=A4=A4=E5=A4j=BE=C7=B8=EA=B0T=AC=EC=A7=DE=AAA=B0=C8=B3B]
: > Email: [email-masked]

: The above is an excellent example of why "just send 8-bits" is
: wrong-headed.  I normally read netnews either in a window that displays
: ISO-8859-1 or ISO-2022-JP.  The above text is in BIG5, the encoding used
: in Taiwan and Hong Kong, and if I display it in a BIG5 xterm it will
: display properly.  In an ISO-8859-1 window the results are, um,
: interesting.

: However, since it was just sent as 8-bits, Pine hasn't the slightest idea
: what character set it is.  I suspect that Pine will innocently apply
: quoted-printable to this message (which isn't bad by itself) but will
: probably label it as ISO-8859-1.  Oops.  Not its fault, though.

: If the posting had been labeled as being MIME CHARSET CN-BIG5, Pine would
: at least have had some warning.

: -- Mark --

: DoD #0105, R90/6 pilot, FAX: (206) 685-4045  ICBM: N 47 39'35" W 122 18'39"
: Science does not emerge from voting, party politics, or public debate.

--
Johnson Chow
------------------------------------------------------------------
E-mail: [email-masked]  PGP 1024-bit key, Key ID 5362C999
Key fingerprint = AB C1 D2 67 59 8D 7D 01  0F D3 C2 1D 85 F0 4B 70
Public key: URL http://www.comp.hkbu.edu.hk/~wschow/pgp.html
------------------------------------------------------------------