Re: Mule-begot problems

Re: Mule-begot problems

[Fabrice.Popineau]

Why should 8bits data be encoded in 7bits if the right Mime headers
are stated ? Sendmail 8.8 handles this in a clever way: when talking
to another mailer, it decides to convert or not 8bits data, depending
on the result of the negociation (ESMTP, Obits uderstood).

Fabrice Popineau

Re: Mule-begot problems

[Jason L Tibbitts III]

>>>>> "Rat" == Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

Rat> Because the MIME specifications say it should, because there are a lot
Rat> of MTAs out there that are not "8-bit clean".

And if my delivery agent recodes to 8-bit before dropping it in my mail spool?

Rat> That is why all of the RFC 822 extensions that address 8-bit data
Rat> specify that it should be encoded into a 7-bit format before
Rat> transmission.

But I don't recall anything that says the mangling cannot be undone upon
receipt.  There are legitimate ways that 8-bit data can end up in a spool
without being sent over the network as 8-bit data.

 - J<

Re: Mule-begot problems

[Russ Allbery]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:
>>>>>> "JLT" == Jason L Tibbitts <tibbs@hpc.uh.edu> writes:

> JLT> And if my delivery agent recodes to 8-bit before dropping it in my
> JLT> mail spool?

> Wonderful for you... but it still technically breaks Internet mail
> standards.  The client is the agent that is supposed to decode the 7-bit
> encoding.

I don't believe the standard actually distinguishes between the local
delivery agent and the client; as soon as the mail is no longer being
transmitted via SMTP, I believe the standard is no longer relevant.

-- 
Russ Allbery (rra@stanford.edu)         <URL:http://www.eyrie.org/~eagle/>

Re: Mule-begot problems

[Russ Allbery]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:
>>>>>> "RA" == Russ Allbery <rra@stanford.edu> writes:

> RA> I don't believe the standard actually distinguishes between the local
> RA> delivery agent and the client; as soon as the mail is no longer being
> RA> transmitted via SMTP, I believe the standard is no longer relevant.

> Not as far as RFC 822 and its extensions are concerned.  These are not
> SMTP standards but the standards that define what is valid in an
> Internet mail message, and they all say, "7-bit ASCII data".

My contention is that as soon as the message is undergoing local delivery,
it is no longer an Internet mail message.

> Besides, MTAs should not perform any modification to a message that is
> not strictly necessary to ensure proper delivery.

The delivery agent is not an MTA.

-- 
Russ Allbery (rra@stanford.edu)         <URL:http://www.eyrie.org/~eagle/>

Re: Mule-begot problems

[Richard Coleman]

> RA> I don't believe the standard actually distinguishes between the local
> RA> delivery agent and the client; as soon as the mail is no longer being
> RA> transmitted via SMTP, I believe the standard is no longer relevant.
> 
> Not as far as RFC 822 and its extensions are concerned.  These are not SMTP
> standards but the standards that define what is valid in an Internet mail
> message, and they all say, "7-bit ASCII data".
> 

This is incorrect.  Checking RFC-822

          Some message systems may  store  messages  in  formats  that
     differ  from the one specified in this standard.  This specifica-
     tion is intended strictly as a definition of what message content
     format is to be passed BETWEEN hosts.


Now mail clients may choose to store messages in a RFC-822 compliant
way, but is a design decision of the client. There isn't any RFC
which specifies a standard format for storing messages locally.

It someone creates an 8-bit clean environment, Mule shouldn't break
this.

-- 
Richard Coleman
coleman@math.gatech.edu

Re: Mule-begot problems

[Steinar Bang]

>>>>> Stainless Steel Rat <ratinox@peorth.gweep.net>:

>>>>> "FP" == Fabrice Popineau <popineau@esemetz.ese-metz.fr> writes:

FP> Why should 8bits data be encoded in 7bits if the right Mime headers are
FP> stated ?

> Because the MIME specifications say it should, because there are a lot of
> MTAs out there that are not "8-bit clean".

> Can you say "legacy system"?

> That is why all of the RFC 822 extensions that address 8-bit data specify
> that it should be encoded into a 7-bit format before transmission.

Actually, I've been using this technique since I first started using
MIME in 1993, ie. mark text/plain; charset=iso-8859-1 as 8bit, and let
the MTA and the recipient worry about the rest.

The reason? Our (ie. the Norwegian email community's) legacy at that
time, was to use ISO8859-1 characters and just-send-8.  If I started
using q-p (or base64 for that matter) on plain text with Norwegian
characters, my correctly marked up article was perceived as broken.

Today I currently have MTAs that does the breaking for me, unless the
MTA they're talking to speaks ESMTP and understands 8BITMIME.  What
happens after the first MTA, I don't worry about.


- Steinar

Re: Mule-begot problems

[Kai Grossjohann]

>>>>> "FP" == Fabrice Popineau <popineau@esemetz.ese-metz.fr> writes:

  FP> Why should 8bits data be encoded in 7bits if the right Mime
  FP> headers are stated ?

>>>>> On 06 Jan 1998, Stainless Steel Rat said:

  Rat> Because the MIME specifications say it should, because there
  Rat> are a lot of MTAs out there that are not "8-bit clean".

Fabrice mentioned that 8bit data is only sent if the receiving end
indicates that it can understand that.  There seems to be a protocol
negotiation of some sort in ESMTP.  I don't see anything wrong with
two instances talking 8bit to each other after previously having
established that they both understand it.

kai
-- 
Kai Grossjohann, Informatik VI        grossjohann@ls6.cs.uni-dortmund.de
Uni Dortmund, D-44221 Dortmund        http://ls6-www.cs.uni-dortmund.de/
                                      Vox +49 231 755 5670, Fax -2405
I like both kinds of music.

Mule-begot problems

[Jon Babcock]

Gentle dingnostica,

What are the problems that Mule introduces to Emacs and Gnus?

I just read in a private response to my last message that it breaks POP. 

Anything else?

I want to mention the most serious Mule-inspired objections to Emacs
20.x and specifically to Gnus in an article I'm writing for
LJ. Actually, the original article was written last March, long before
the official Emacs-Mule merge, and now that LJ is finally getting
around to schedule it for printing, I find that a number of those who
belong to the Faith of Emacs are crying out ... in pain. Anybody know
why?

It doesn't use Unicode and the documentation stinks * ... I know about these.

Jon Babcock
jon@kanji.com

* In April, 1995, I bought a book on Mule that turned out to be mostly
on Emacs (in Japanese, ISBN4-7561-0300-6) and that helped
slightly. And I looked through some of the early Japanese
documentation, too, which allowed me to at least install and run
it. Sort of. But it wasn't until Stallman wrote the info stuff that
was to end up accompanying Emacs 20.1 that I could get the beginning
of an overview. (Yeah, I know, I'm dumb or I guess so ...)

Re: Mule-begot problems

[Tore Olsen]

Jon Babcock <jon@kanji.com> writes:

> Gentle dingnostica,
> 
> What are the problems that Mule introduces to Emacs and Gnus?
> 
> I just read in a private response to my last message that it breaks POP. 
> 
> Anything else?

If you want arguments against MULE, I suggest you contact Erik Naggum
<erik@naggum.no>. He's one of the GNU Emacs maintainer and probably
the one crying out loudest against Mule.

-Toreo
-- 
Surprise, fear, and a ruthless dedication to the Gnu!

Re: Mule-begot problems

[Jon Babcock]

I've taken Tore Olsen's advice and have written to Erik Naggum. Thanks.

I should have focused my question more specifically. What Mule-related
problems have Gnus developers experienced? 

To read and write to mailing lists and newsgroups that use Japanese
and Chinese, I need Gnus. To write articles and monographs that
include CJK scripts, I need Emacs. If it were a question of only one
script, say Japanese, then I could run a nipponized version of Linux,
use kterm, etc. But it is precisely the ability to deal with multiple
scripts that makes the new Emacs so attractive to me, whose background
is classical Chinese and Buddhist prajnaparamita studies. I want to
see that multi-script functionality become a solid part of Emacs so
that Emacs offers the best solution in this area available anywhere.

Jon Babcock
jon@kanji.com