Subject: Line length, quoted printable, usenet posting

From: [email-masked] (Alan J. Flavell)
Date: Thu, 4 Jan 1996 19:21:36 GMT

I'm finding that if I use ctrl/J to tidy up my untidy input, it's
inclined to trigger PINE into quoted-printable mode: I assume that
this is happening because I've exceeded the max line length that
PINE permits in a non-encoded plain mail.

When the result is intended as a usenet posting, this gets
complaints from other usenauts about the =20 and =3D and stuff.
Many usenet readers don't support MIME and display the stuff raw
to the readers.

Can I do anything, in terms of 1/ reducing the max line length
produced by ctrl/J, or 2/ discouraging PINE from going into
quoted-printable mode in this situation, or 3/ at least giving
some kind of indication that I have provoked it (as could also
happen, for example, if I typed a pound-sterling character in).

Preferably via a configuration parameter (but I looked and
didn't see one) rather than having to rebuild the software.

best regards

---

From: [email-masked] (Andreas Klemm)
Date: 4 Jan 1996 20:40:24 GMT

>didn't see one) rather than having to rebuild the software.

I asked that, too, the answer was, that quoted printable is
an internet standard. The authors wonder about the fact, that
so many people want to have a switch to turn it off.
I think they'd prefer, that other mail packages should start
to support the MIME capabilities and quoted printable as well.

If I remember right they think about it, to include such a switch
into the next pine release.

Another thing I'd like to see is, to have a configuration
parameter, that allows you to encode binaries with uuencode.

When I send binary data from home to my sun, I have problems
to get it unpacked. I'd have to compile pine or another package,
to get it decoded. I hope pine will get such feature, too.

-- 
[email-masked]       /\/\___  Wiechers & Partner Datentechnik GmbH
   Andreas Klemm        ___/\/\/       - Support Unix - [email-masked] -
                             \/
       ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz
apsfilter - magic print filter 4lpd  >>> knobel is powered by FreeBSD <<<

---

From: "Alan J. Flavell" <[email-masked]>
Date: Fri, 5 Jan 1996 10:35:52 GMT

On 4 Jan 1996, Andreas Klemm wrote:

> >produced by ctrl/J, ...
> an internet standard.  ...

It is, but it's not mandatory even for email yet, and certainly
support for it is not widespread on usenet.  I don't believe it
is polite to use MIME encoding on usenet.  PINE is a nice email 
client but I'm not exactly impressed by it as a usenet client; 
it's just that I'm sometimes in a position where it's the only 
usenet client that's easily accessible to me as a user - I just
wish that it was better behaved on usenet in this (and some other) 
respects.

Could I just say again that I'd be content if I had a way to
cut down the line length somewhat that ctrl/J produces.  Is this
a PICO issue?  I guess it is.  Does PICO have any handles on this,
like a configuration file (rather than needing to rebuild from
source)?

best regards

---

From: [email-masked] (Egil Kvaleberg)
Date: Sun, 7 Jan 1996 07:40:19 GMT

> > >Many usenet readers don't support MIME and display the stuff raw

I find the current situation where programs like Pine and Netscape
switches to Mime Printables whenever they see one little 8-bit
character very unfortunate. RFC1340 clearly indicates the possibility
of sending straight 8bit. As long as this is announced in the
header, I really think that this is a good thing:

     Content-Type: TEXT/PLAIN; charset=iso-8859-1
     Content-Transfer-Encoding: 8BIT

> I don't believe it
> is polite to use MIME encoding on usenet.

If you by MIME encoding mean "Quoted Printable", I 100% agree.
I even think its use for email should be limited too.

That is why I have made a patch for Pine 3.91 to allow proper
8bit postings. A feature switch "allow-8bit-mime" has been 
introduced to enable this feature. The 8bit coding for text is
used for situations where all these conditions are met:

	1. The "allow-8bit-mime" feature is set.
	2. One or more character has the upper bit set.
	3. None of these characters are unprintable.
	4. Less than 30% of the characters require 8bit.
	5. The line length is below 500.
	6. There are no NULs.

Please email me at [email-masked] if you are interested.

Egil

--
Email: [email-masked]	  Voice: +47 22523641 Fax: +47 22525899
Snail: Egil Kvaleberg, Husebybakken 14A, 0379 Oslo, Norway
URL:   http://www.oslonett.no/home/egilk/

---

From: Terry Gray <[email-masked]>
Date: Mon, 22 Jan 1996 15:20:48 -0800 (PST)

Egil,
I'm concerned about a statement you make below in your msg of 7 January:
"RFC1340 clearly indicates the possibility of sending straight 8bit."

I believe this is at best misleading, if not incorrect.  (NB: "RFC1340" is
presumably a typo, but note that 1341 is superseded by 1521.)

MIME provides a method for labeling and encoding content.  It does *not*
specify what is legal to send via any given transport.  What's legal to
*send* is defined by RFC821 and its successors.  With the current Internet
mail transport infrastructure, it is not sufficient simply to "announce"
8bit in the header; indeed, as far as I know, there is no Internet
standard *anywhere* that says it's OK to send unencoded 8bit (much less,
binary) data *unless* by explicit negotiation with the MTA via the
8BITMIME extension to (E)SMTP defined in RFC-1426.

Here's the relevant text from the MIME standard:

 NOTE: The distinction between the Content-Transfer-Encoding values
      of "binary", "8bit", etc.  may seem unimportant, in that all of
      them really mean "none" -- that is, there has been no encoding of
      the data for transport.  However, clear labeling will be of
      enormous value to gateways between future mail transport systems
      with differing capabilities in transporting data that do not meet
      the restrictions of RFC 821 transport.

      Mail transport for unencoded 8-bit data is defined in RFC-1426
      [RFC-1426].  As of the publication of this document, there are no
      standardized Internet mail transports for which it is legitimate
      to include unencoded binary data in mail bodies.  Thus there are
      no circumstances in which the "binary" Content-Transfer-Encoding
      is actually legal on the Internet.  However, in the event that
      binary mail transport becomes a reality in Internet mail, or when
      this document is used in conjunction with any other binary-capable
      transport mechanism, binary bodies should be labeled as such using
      this mechanism.

Because we take some pride in Pine's adherence to Internet standards, it
is always painful to see folks distributing patches, such as your
"just-send-8" patch, which cause Pine to *violate* Internet standards.
This is not to say that I *like* the limitations of 821, only that we
are committed to interoperability via Internet standards adherence.
As you know, Pine 3.92 will support ESMTP negotiation of 8BITMIME
transport, which is the standards-based solution to the problem.

-teg

---

From: [email-masked] (Egil Kvaleberg)
Date: Thu, 25 Jan 1996 13:56:54 GMT

Terry Gray ([email-masked]) wrote:
> MIME provides a method for labeling and encoding content.

	================================================================
	For the benefit of readers who do not normally receive messages  
	in the Mime Quoted Printable format, I have converted this little
	passage to QP as shown below. To add a little realism to it, I 
	have let the letters A, E and O undergo QP-coding, and added
	the odd extra blank here and there.			   
	================================================================

=09=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=09F=6Fr th=65 b=65n=65fit =6Ff r=65=61d=65rs wh=6F d=6F n=6Ft n=6Frm=61lly=
 r=65c=65iv=65 m=65ss=61g=65s =20
=09in th=65 Mim=65 Qu=6Ft=65d Unr=65=61d=61bl=65 f=6Frm=61t, I h=61v=65 c=
=6Fnv=65rt=65d this littl=65=20
=09p=61ss=61g=65 t=6F QP =61s sh=6Fwn =61b=6Fv=65. T=6F =61dd =61 littl=65 =
r=65=61lism t=6F it, I=20
=09h=61v=65 l=65t th=65 l=65tt=65rs =41, =45 =61nd =4F und=65rg=6F QP-c=6Fd=
ing, =61nd =61dd=65d =20
=09th=65 =6Fdd =65xtr=61 bl=61nk h=65r=65 =61nd th=65r=65.=09=09=09  =20
=09=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Now imagine that you are one of the vast number of mail recipients not
having QP support, and you receive mail written in any of the many
languages that require ISO-8859 characters. I have excluded QP info in
the header to illustrate the impression this makes on the reader. I
hope you will now understand the essence of the rationale behind
RFC1428:
	This existing functionality is reduced by conversion	     
	from 8bit text to text encoded in unreadable Base-64
	or "garbled" text encoded in quoted printable.

I think that you will agree that such a message as shown in my example
is really more or less completely garbled from the recipients point of 
view, indeed "Quoted Unreadable" :-). 

> What's legal to

But there are many indications from RFCs that such a practice is
indeed commonplace. And RFC1428 "Transition of Internet Mail from
Just-Send-8 to 8Bit-SMTP/MIME" clearly discuss the problems generated
by uncritical use of MIME QP. 

And as mentioned in RFC1428, ISO-8859 8 bit messages having been
subjected to 7 bit stripping is usually more readable that QP-ed
messages anyway.

To warn against such problems, the help message for the new
"allow-8bit-mail" feature reads:				     
	This feature controls the manner in which outgoing email messages
	containing characters outside the (7bit) US-ASCII set are coded.
	...
	Regretfully, all email agents are not yet 8 bit clean. Consequently,
	depending on the path email travels, one runs a certain risk that
	8 bit characters will become corrupted if this feature is enabled.

> Here's the relevant text from the MIME standard:
..
>   Thus there are
>   is actually legal on the Internet.

Please read the text carefully. It says "binary", not "8bit". There
is a big difference. I've *never* said that "binary" coding should be
attempted! 8bit coding involves handling of message regarded as text,
which includes adherence to line length restrictions. As an extra 
precaution against problems by upper bit stripping, I have not allowed 
characters in the range 80-9F, plus FF.

> "just-send-8" patch, which cause Pine to *violate* Internet standards.

I *do* understand that you take pride in Pine. It is a very good mail
reader, and additionally the source code is very clearly and orderly
piece of software. That is why I use it myself.

If I have caused pain, I deeply apologize. That was not intentional.
I hope I have shown that I have taken precautions to keep this as
conforming to current standards and practice as possible. 

Please also consider that Pine's use of Mime QP on Usenet is considered
a definitive violation. Plus the fact that Pine violates RFC1036 in the
way signatures are handled. And from my experience, sending Mime QP in 
email is an impolite thing to do, if not a violation. My patch tries
to correct these things.

> are committed to interoperability via Internet standards adherence.

Luckily, 8 bit restrictions are now practically out of the way with
respect to news. I hope that we can soon come in a position where
they will be removed in mail too, and finally also in header subject
lines and the like.

> transport, which is the standards-based solution to the problem.

But why do you want to exclude all those who do not use the Pine SMTP
server? Why on earth shouldn't at least the sysadmin allow Pine to  
understand that "ESMTP is spoken here"?

A final point: In that we agree that 8bit mail is a Good Thing, how
on earth can we ensure that it will be implemented unless we start
using it. Many sysadmins will not start converting their sendmail
"O7True" settings to "O7False" without a certain degree of pressure
put on them.

Egil

PS: The patch is available from:

	ftp://ftp.sn.no/user/egilk/patch.pine3.91PL1.gz

It also corrects a couple of minor things regarding exported messages
and signatures.

--
Email: [email-masked]  Voice: +47 22523641, 92022780 Fax: +47 22525899
Snail: Egil Kvaleberg, Husebybakken 14A, 0379 Oslo, Norway
URL:   http://www.sn.no/~egilk/

---

From: Terry Gray <[email-masked]>
Date: Thu, 25 Jan 1996 09:32:10 -0800 (PST)

> > MIME provides a method for labeling and encoding content.

 <I have omitted Egil's humorous demonstration of how to make QP look
  worse than it really is in practice.>

> indeed commonplace.

I challenge you to find *any* Internet standard that says it's OK to
"just-send-8" in email.  I can't be responsible for other's violations of
the standards, so "commonplace" doesn't cut it.  (News is different; we
agree that Pine should support just-send-8 for News, and it will --even
though some in the community hold that this would be a mistake.)

> And RFC1428 "Transition of Internet Mail from

The issue is not that QP is wonderful, it is that unencoded 8bit is
illegal, except by explicit negotiation.

> subjected to 7 bit stripping is usually more readable that QP-ed

Absolutely!  And if your patch was to provide an option for stripping the
8th bit rather than "just-send-8", I would have no objection; indeed, we
might have adopted it.

> characters in the range 80-9F, plus FF.

I have read the text carefully, and if you do the same, I'm sure you'll
conclude that the *next* paragraph cited makes it clear that the only
legitimate way to send 8bit in the current Internet email infrastructure
is via the 8BITMIME extension defined in RFC-1426.

> Plus the fact that Pine violates RFC1036 in the
> way signatures are handled.

Are you saying that you are unable to create a .signature file that is
1036 compliant?  It's true that Pine doesn't *enforce* any particular
signature discipline, but I think it is misleading to say it violates the
standard when it is perfectly possible for you to configure it to comply.
But this is *way* off topic.

> And from my experience, sending Mime QP in email is an impolite thing to
> do, if not a violation.

It may be impolite, but it is certainly not a violation.  And sympathy for
recipients who in 1996 still don't have MIME-capable mail readers (which
makes the QP encoding invisible to the user) must be limited, since there
are so many MIME-aware tools freely available.  (Ironically, later in your
message you argue that people won't change without some pressure to do
so!)

> My patch tries to correct these things.

It does so by making our mailer violate Internet standards.  This is not
helpful.  If you don't like the standards, participate in the IETF and get
them changed.  Again, if the patch was to strip the 8th bit to avoid QP,
or to support the 8BITMIME extension, there would be no argument.

> they will be removed in mail too, and finally also in header subject

I would prefer this world, too, but it is not the one we live in.

> understand that "ESMTP is spoken here"?

I don't understand what you're saying.  I don't know what a "Pine SMTP
server" is; Pine works with any SMTP server, and in the future it will
take advantage of at least one ESMTP extension:  Pine 3.92 will indeed
allow the sysadmin to say "ESMTP is spoken here", via the option to
negotiate 8BITMIME.

> "O7True" settings to "O7False" without a certain degree of pressure

Orderly migration is the IETF strategy, and that's what ESMTP and 8BITMIME
are all about.

It comes down to this:  You've decided that the world will be a better
place if the Internet standards are ignored and we all "just-send-8".
Although I'm sympathetic to the goal, (as previously stated) we are
committed to interoperability via Internet standards, so cannot endorse
your means to that end.

I'm sure we could continue this debate indefinitely, but let's just agree
to disagree.

-teg

---

From: Rahul Dhesi <[email-masked]>
Date: 26 Jan 1996 13:05:27 GMT

...
>is via the 8BITMIME extension defined in RFC-1426.

Minor nit: 'illegal' and 'legitimate' are orthogonal to 'RFC-conforming'.

On second thoughts, make that 'Major nit'.  Too many people confuse
between RFC conformance and various other qualities such as legality,
legitimacy, usefulness, validity, workability, interoperability, and
user-friendliness.  They forget that RFC conformance is a means to an
end, not the end.
-- 
Rahul Dhesi <[email-masked]>
==
"...Mark Crispin has the good sense to not blather away in
 newsgroups..." -- Wayne Hathaway