Re: RMAIL, MIME clean-up, coding system

Re: RMAIL, MIME clean-up, coding system

[Richard Stallman]

    That's exactly what I have proposed: to encode them (text bodyparts)
    back into US-ASCII stream using base64 method.

I am not really sure what that means.  Could you explain?

Anyway, the first idea that occurs to me is to edit the headers of the
mime attachments to say how they are really encoded.  Why not?

Re: RMAIL, MIME clean-up, coding system

[Alexander Pohoyda]

Richard Stallman <rms@gnu.org> writes:

>     That's exactly what I have proposed: to encode them (text
>     bodyparts) back into US-ASCII stream using base64 method.
> 
> I am not really sure what that means.  Could you explain?

The basic problem is here once again:
We read emails from inbox file and store them into RMAIL file, doing
some processing on the way. This processing includes base64 and
quoted-printable decoding. Now, to export this email back to file
(rmail-output function) we have two ways:
a) write it using emacs-mule coding system;
b) encode bodyparts which need to be encoded using base64 or
quoted-printable "transfer encoding" and save the file as US-ASCII.

Solution (a) has a clear disadvantage that such a file may only be
visited by Emacs. Well, this is such a big disadvantage that I don't
buy this solution at all.

Solution (b) is more complicated and, in fact, does the action
reversed to what we did with an email in the first place.
Hopefully we don't have to do this too often.
So another question arises: does it make sence to do the initial
processing in the first place?
The fact is that we already do some processing, namely: we insert
the extra "simplified" header between the original header and the
message body.

Both solutions do not need the X-Coding-System header field, which I
mentioned before.
Do I oversee something?


> Anyway, the first idea that occurs to me is to edit the headers of
> the mime attachments to say how they are really encoded.  Why not?

Yes, this is already done.
Imagine that we have a message with two bodyparts of type text/plain.
One of them is encoded using koi8-r and another is a utf-8 text.
We know this, and we can show the message in the buffer.

The problem is here: how to export it into the file?


-- 
Alexander Pohoyda <alexander.pohoyda@gmx.net>
PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72  15 54 5F 62 20 23 C6 44

Re: RMAIL, MIME clean-up, coding system

[Eli Zaretskii]

[I think this discussion belongs to the development list; redirected.]

> Date: Sun, 5 Oct 2003 12:53:18 +0200 (CEST)
> From: Alexander Pohoyda <alexander.pohoyda@gmx.net>
> 
> Using a message-global X-Coding-System header field is not an option
> anymore.

Sorry, I don't see why not; we could, for example, use emacs-mule,
right?

> The only solution I see is to base64/quoted-printable encode
> entities before saving the message to file.
> 
> Comments, please?

Yuck!  (Sorry, couldn't resist: I _hate_ encodings that aren't
readable by humans outside specialized software.)

Re: RMAIL, MIME clean-up, coding system

[Alexander Pohoyda]

> > Using a message-global X-Coding-System header field is not an option
> > anymore.
> 
> Sorry, I don't see why not; we could, for example, use emacs-mule,
> right?

What do we do when we save an email to the file? Am I right that the
file encoded using emacs-mule will only be readable by Emacs?

> > The only solution I see is to base64/quoted-printable encode
> > entities before saving the message to file.
> > 
> > Comments, please?
> 
> Yuck!  (Sorry, couldn't resist: I _hate_ encodings that aren't
> readable by humans outside specialized software.)

Do you mean base64 or emacs-mule encoding here?
Non-specialized software is not able to correctly show you the file
which contains parts encoded in different coding systems, is it?


-- 
Alexander Pohoyda <alexander.pohoyda@gmx.net>
PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72  15 54 5F 62 20 23 C6 44

Re: RMAIL, MIME clean-up, coding system

[Eli Zaretskii]

> Date: Tue, 7 Oct 2003 23:36:06 +0200 (CEST)
> From: Alexander Pohoyda <alexander.pohoyda@gmx.net>
> 
> > > Using a message-global X-Coding-System header field is not an option
> > > anymore.
> > 
> > Sorry, I don't see why not; we could, for example, use emacs-mule,
> > right?
> 
> What do we do when we save an email to the file?

We encode it in emacs-mule (reagrdless of what X-Coding-System
says).  This is so with Emacs today.

> Am I right that the
> file encoded using emacs-mule will only be readable by Emacs?

The ASCII parts will be readable, unlike base64, for example.

> > Yuck!  (Sorry, couldn't resist: I _hate_ encodings that aren't
> > readable by humans outside specialized software.)
> 
> Do you mean base64 or emacs-mule encoding here?

base64, of course.  In too many cases, it makes human-readable text
incomprehensible.  We should at least allow to read the 7-bit ASCII.

Re: RMAIL, MIME clean-up, coding system

[Stefan Monnier]

> [I think this discussion belongs to the development list; redirected.]

The context is missing.

>> Using a message-global X-Coding-System header field is not an option
>> anymore.
> Sorry, I don't see why not; we could, for example, use emacs-mule,
> right?

Just a reminder that we shouldn't fiddle too much with the encoding of MIME
email since things like gpg signatures might otherwise get broken.
I recommend using the "transport encoding" as is: after all, we have
to handle this encoding anyway.

Of course, for lack of context, I might be barking up the wrong tree.


        Stefan

Re: RMAIL, MIME clean-up, coding system

[Alexander Pohoyda]

> >> Using a message-global X-Coding-System header field is not an option
> >> anymore.
> > Sorry, I don't see why not; we could, for example, use emacs-mule,
> > right?
> 
> Just a reminder that we shouldn't fiddle too much with the encoding
> of MIME email since things like gpg signatures might otherwise get
> broken.

AFAIK, only ASCII armor is used to sign email messages. Even if this
is not always the case, 8bit data is recommended to send base64
encoded, so I don't really understand your concern.
Anyway, with my implementation we are free to do whatever we need
with any content type, so if this is not a text type, we don't even
*have* to transfer-encoding decode it. We don't even have to show it
in the message.

Please feel free to explain what you mean. I appreciate your input
very much.


-- 
Alexander Pohoyda <alexander.pohoyda@gmx.net>
PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72  15 54 5F 62 20 23 C6 44

Re: RMAIL, MIME clean-up, coding system

[Stefan Monnier]

>>>>> "Alexander" == Alexander Pohoyda <alexander.pohoyda@gmx.net> writes:
>> >> Using a message-global X-Coding-System header field is not an option
>> >> anymore.
>> > Sorry, I don't see why not; we could, for example, use emacs-mule,
>> > right?
>> Just a reminder that we shouldn't fiddle too much with the encoding
>> of MIME email since things like gpg signatures might otherwise get
>> broken.
> AFAIK, only ASCII armor is used to sign email messages. Even if this

I meant that changing the coding-system of a text message will break
the gpg signature.


        Stefan

Re: RMAIL, MIME clean-up, coding system

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Date: 07 Oct 2003 17:59:46 -0400
> 
> The context is missing.

There was none; see the original message on gnu.emacs.bug.

> I recommend using the "transport encoding" as is: after all, we have
> to handle this encoding anyway.

Could you please explain what do you mean by "transport encoding"?

Re: RMAIL, MIME clean-up, coding system

[Stefan Monnier]

>> I recommend using the "transport encoding" as is: after all, we have
>> to handle this encoding anyway.
> Could you please explain what do you mean by "transport encoding"?

The way the message was represented as a binary stream in the mailbox
before Emacs started to mess with it.


        Stefan