More on forwarding quoted-printable encoded messages

More on forwarding quoted-printable encoded messages

[Carey Evans]

[-- Attachment #1: Type: text/plain, Size: 1421 bytes --]

I've been looking into my problems with forwarding messages some more,
and I believe I've found two separate bugs in Gnus.  If you're not
convinced, could you let me know what else you'd like to me to look
into?

I'm including my original message below.  This time I edited and
resent it as an 8bit encoded message.  If this works the same sending
to the Gnus mailing list as it did to myself, the attached message
will look fine.

Bug 1:  If I press C-d on this message and view the attachment, the
special characters "=" and "ê" show up as their quoted-printable
equivalents, even though the attachment looks fine as I compose the
message, and the entire message looks correct.  A variation on this
would be why my original forwarded message looked wrong in the
complete view, but OK given Kai's suggestion to use C-d.

Bug 2:  When viewing a quoted-printable encoded message, forward it
with S o m.  The message in the buffer includes a header line

    Content-Transfer-Encoding: quoted-printable

but the actual data in the message has been decoded.  When Gnus, Lotus
Notes, mutt and probably other mailers (though not the mailing list
archives) receive the message, they decode it for quoted-printable
again, resulting in the error I had.

If I manually edit the message in the *mail* buffer and change the =
to =3D and the ê to =EA, the message is encoded and received properly.




[-- Attachment #2: Type: message/rfc822, Size: 808 bytes --]

Return-path: <carey@paradise.net.nz>
To: carey@psyche.evansnet
Subject: Forwarding quoted-printable encoded messages
From: Carey Evans <c.evans@clear.net.nz>
Date: 23 Jan 2000 18:27:15 +1300
Message-ID: <87wvp1e4ss.fsf@psyche.evansnet>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

I've found a problem in Gnus v5.8.3 (with XEmacs 21.1 p8) when
forwarding messages (with S o m) that I've received with
quoted-printable encoded equals sign characters.  In particular, this
was with a URL like the following:

    http://www.invalid/lookup?id=EA123456

That's "? i d equals E A ...".  I'm forwarding this message at the
bottom of this one, which should show the problem.  When I receive
this message, I see the character at 0xea, i.e. "ê".

From: Carey Evans <c.evans@clear.net.nz>
To: carey@psyche.evansnet
Subject: Forwarding quoted-printable encoded messages
Date: 23 Jan 2000 18:27:15 +1300
Message-ID: <87wvp1e4ss.fsf@psyche.evansnet>


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2.1: Type: text/plain; charset=3Diso-8859-1, Size: 460 bytes --]

From: Carey Evans <c.evans@clear.net.nz>
To: carey@psyche.evansnet
Subject: Forwarding quoted-printable encoded messages
Date: 23 Jan 2000 18:27:15 +1300
Message-ID: <87wvp1e4ss.fsf@psyche.evansnet>

I've found a problem in Gnus v5.8.3 (with XEmacs 21.1 p8) when
forwarding messages (with S o m) that I've received with
quoted-printable encoded equals sign characters.  In particular, this
was with a URL like the following:

    http://www.invalid/lookup?id=3DEA123456

That's "? i d equals E A ...".  I'm forwarding this message at the
bottom of this one, which should show the problem.  When I receive
this message, I see the character at 0xea, i.e. "=EA".

[-- Attachment #3: Type: text/plain, Size: 163 bytes --]


-- 
	 Carey Evans  http://home.clear.net.nz/pages/c.evans/

	 This message was composed from the finest electrons
	 used by many of the world's greatest writers.

Re: More on forwarding quoted-printable encoded messages

[Lars Magne Ingebrigtsen]

Carey Evans <c.evans@clear.net.nz> writes:

> Bug 1:  If I press C-d on this message and view the attachment, the
> special characters "=" and "ê" show up as their quoted-printable
> equivalents, even though the attachment looks fine as I compose the
> message, and the entire message looks correct.  A variation on this
> would be why my original forwarded message looked wrong in the
> complete view, but OK given Kai's suggestion to use C-d.

Hm, yes, when selecting the message/rfc822 part in the nndoc buffer,
the qp decoding isn't performed.  Which is kinda logical looking at
the code, since the message/rfc822 is a bit special.

> Bug 2:  When viewing a quoted-printable encoded message, forward it
> with S o m.  The message in the buffer includes a header line
> 
>     Content-Transfer-Encoding: quoted-printable
> 
> but the actual data in the message has been decoded.  When Gnus, Lotus
> Notes, mutt and probably other mailers (though not the mailing list
> archives) receive the message, they decode it for quoted-printable
> again, resulting in the error I had.

Yes...  Would removing the CTE header be the right thing to do, I
wonder?  The message/rfc822 thing should possibly be given a
re-think. 

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: More on forwarding quoted-printable encoded messages

[Steinar Bang]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

> Carey Evans <c.evans@clear.net.nz> writes:
>> Bug 1:  If I press C-d on this message and view the attachment, the
>> special characters "=" and "ê" show up as their quoted-printable
>> equivalents, even though the attachment looks fine as I compose the
>> message, and the entire message looks correct.  A variation on this
>> would be why my original forwarded message looked wrong in the
>> complete view, but OK given Kai's suggestion to use C-d.

> Hm, yes, when selecting the message/rfc822 part in the nndoc buffer,
> the qp decoding isn't performed.  Which is kinda logical looking at
> the code, since the message/rfc822 is a bit special.

Yes.  But Gnus does it wrong when it q-ps the message/rfc822 part, I
think (I sent a bug report for this).  Shouldn't the message itself be
q-p if neccessary?

Right now Gnus, Netscape and Outlook, and OE croaks on attached
messages with charset iso-8859-1, sent by Gnus.

Re: More on forwarding quoted-printable encoded messages

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@metis.no> writes:

> Yes.  But Gnus does it wrong when it q-ps the message/rfc822 part, I
> think (I sent a bug report for this).  Shouldn't the message itself be
> q-p if neccessary?

Yes.  But what if you're forwarding something with 8bit headers?
(I remember the RFCs saying this is a no-no, but, er.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: More on forwarding quoted-printable encoded messages

[Steinar Bang]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

> Steinar Bang <sb@metis.no> writes:
>> Yes.  But Gnus does it wrong when it q-ps the message/rfc822 part, I
>> think (I sent a bug report for this).  Shouldn't the message itself be
>> q-p if neccessary?

> Yes.  But what if you're forwarding something with 8bit headers?
> (I remember the RFCs saying this is a no-no, but, er.)

According to the relevant quote from the MIME standards (the one in my
bug report is inconclusive)
	http://www.ietf.org/rfc/rfc2046.txt
section 5.2.1 (covering message/rfc822), last paragraph:

   No encoding other than "7bit", "8bit", or "binary" is permitted for
   the body of a "message/rfc822" entity.  The message header fields are
   always US-ASCII in any case, and data within the body can still be
   encoded, in which case the Content-Transfer-Encoding header field in
   the encapsulated message will reflect this.  Non-US-ASCII text in the
   headers of an encapsulated message can be specified using the
   mechanisms described in RFC 2047.

it would seem that the headers should be RFC2047-ified if neccessary.

Re: More on forwarding quoted-printable encoded messages

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@metis.no> writes:

> it would seem that the headers should be RFC2047-ified if neccessary.

Yup.  Fix in Gnus v5.8.5.

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: More on forwarding quoted-printable encoded messages

[Steinar Bang]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

> Steinar Bang <sb@metis.no> writes:
>> it would seem that the headers should be RFC2047-ified if neccessary.

> Yup.  Fix in Gnus v5.8.5.

But it is not in the reporitory yet?  I did a checkout today, and it
has the same behaviour as before.

Re: More on forwarding quoted-printable encoded messages

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@metis.no> writes:

> But it is not in the reporitory yet?  I did a checkout today, and it
> has the same behaviour as before.

I've tested it on a couple of messages, and it rfc2047-encoded the
forwarded message for me...  How do you produce this bug?

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: More on forwarding quoted-printable encoded messages

[Steinar Bang]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

> Steinar Bang <sb@metis.no> writes:
>> But it is not in the reporitory yet?  I did a checkout today, and it
>> has the same behaviour as before.

> I've tested it on a couple of messages, and it rfc2047-encoded the
> forwarded message for me...  How do you produce this bug?

I haven't tried it on a message with 8bit characters in the headers,
but when I try forwarding a text/plain; charset=iso-8859-1 message, I
get the following headers if I do C-u on the rfc822 part after doing a 
C-d (ie. the message/rfc822 c-t-e, is still q-p, which is disallowed by RFC
2046, section 5.2.1 (only 7bit, 8bit and binary allowed)):

To: Steinar Bang <sb@metis.no>
Subject: ["Espen OEyen" <esoeyen@c2i.net>] Re: Da var det gjort
BCC: sb@metis.no
From: Steinar Bang <steinar@bang.priv.no>
Date: 23 Apr 2000 21:43:15 +0200
Message-ID: <whd7ng38oc.fsf@viffer.metis.no>
User-Agent: Gnus/5.0805 (Gnus v5.8.5) XEmacs/20.4 (Emerald)
MIME-Version: 1.0
Content-Type: message/rfc822; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

X-From-Line: esoeyen@c2i.net  Thu Apr 13 09:06:13 2000
Return-Path: <esoeyen@c2i.net>
Received: from localhost (sb@localhost [127.0.0.1])
	by viffer.metis.no (8.9.3/8.9.3) with ESMTP id JAA14154
	for <sb@localhost>; Thu, 13 Apr 2000 09:06:12 +0200
Received: from tyr.metis.no
	by localhost with IMAP (fetchmail-5.1.0)
	for sb@localhost (single-drop); Thu, 13 Apr 2000 09:06:12 +0200 (MEST)=

Received: by metis.no (8.9.1/8.9.1) with ESMTP id WAA12278; Wed, 12 Apr=
 2000 22:31:01 +0200 (MET DST)
Received: by gw.metis.no (8.9.1/8.9.1) with ESMTP id WAA07136; Wed, 12 =
Apr 2000 22:30:40 +0200 (MET DST)
Received: from default (mp-39-14.daxnet.no [193.216.39.14])
	by golf.dax.net (8.9.3/8.9.3) with SMTP id WAA11626
	for <steinar@bang.priv.no>; Wed, 12 Apr 2000 22:29:52 +0200 (MET DST)
=
X-Gnus-Mail-Source: file:/var/spool/mail/sb
Message-ID: <001901bfa4bd$bc6568c0$0e27d8c1@default>
Reply-To: "Espen OEyen" <esoeyen@c2i.net>
From: "Espen OEyen" <esoeyen@c2i.net>
To: "Steinar Bang" <steinar@bang.priv.no>
References: <38e61a57.13531740@news.online.no> <5fpF4.4591$%u.329986@ju=
liett.dax.net> <whzor58zfx.fsf@viffer.metis.no> <000701bfa177$edeee5e0$=
addad9c1@default> <wh66tr4k8m.fsf@viffer.metis.no>
Subject: Re: Da var det gjort
Date: Wed, 12 Apr 2000 22:28:57 +0200
Organization: M=F8ller
MIME-Version: 1.0
Content-Type: text/plain;
	charset=3D"iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
X-MIME-Autoconverted: from quoted-printable to 8bit by metis.no id WAA1=
2278

Re: More on forwarding quoted-printable encoded messages

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@metis.no> writes:

> I haven't tried it on a message with 8bit characters in the headers,
> but when I try forwarding a text/plain; charset=iso-8859-1 message, I
> get the following headers if I do C-u on the rfc822 part after doing a 
> C-d (ie. the message/rfc822 c-t-e, is still q-p, which is disallowed by RFC
> 2046, section 5.2.1 (only 7bit, 8bit and binary allowed)):

Could you try again with the cvs that will be available in a few
minutes? 

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: More on forwarding quoted-printable encoded messages

[Steinar Bang]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

> Steinar Bang <sb@metis.no> writes:
>> I haven't tried it on a message with 8bit characters in the headers,
>> but when I try forwarding a text/plain; charset=iso-8859-1 message, I
>> get the following headers if I do C-u on the rfc822 part after doing a 
>> C-d (ie. the message/rfc822 c-t-e, is still q-p, which is disallowed by RFC
>> 2046, section 5.2.1 (only 7bit, 8bit and binary allowed)):

> Could you try again with the cvs that will be available in a few
> minutes? 

I didn't try then (wasn't online), but I tried with a checkout from
just before 20:00 MET DST tonight.  But it looks the same.

The original message I'm trying to forward has a c-t-e of 8bit.  I'm
wondering if things had been different if it had been q-p, but I don't 
know how to force a q-p message in the folders, so I don't know how to 
test this.

Here are the results from C-u in the "rfc822" part after doing C-d on
the message containing the forwarded message.

To: Steinar Bang <sb@metis.no>
Subject: ["Espen OEyen" <esoeyen@c2i.net>] Re: Da var det gjort
BCC: sb@metis.no
From: Steinar Bang <steinar@bang.priv.no>
Date: 24 Apr 2000 19:59:16 +0200
Message-ID: <whitx7mlcb.fsf@viffer.metis.no>
User-Agent: Gnus/5.0805 (Gnus v5.8.5) XEmacs/20.4 (Emerald)
MIME-Version: 1.0
Content-Type: message/rfc822; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

X-From-Line: esoeyen@c2i.net  Thu Apr 13 09:06:13 2000
Return-Path: <esoeyen@c2i.net>
Received: from localhost (sb@localhost [127.0.0.1])
	by viffer.metis.no (8.9.3/8.9.3) with ESMTP id JAA14154
	for <sb@localhost>; Thu, 13 Apr 2000 09:06:12 +0200
Received: from tyr.metis.no
	by localhost with IMAP (fetchmail-5.1.0)
	for sb@localhost (single-drop); Thu, 13 Apr 2000 09:06:12 +0200 (MEST)=

Received: by metis.no (8.9.1/8.9.1) with ESMTP id WAA12278; Wed, 12 Apr=
 2000 22:31:01 +0200 (MET DST)
Received: by gw.metis.no (8.9.1/8.9.1) with ESMTP id WAA07136; Wed, 12 =
Apr 2000 22:30:40 +0200 (MET DST)
Received: from default (mp-39-14.daxnet.no [193.216.39.14])
	by golf.dax.net (8.9.3/8.9.3) with SMTP id WAA11626
	for <steinar@bang.priv.no>; Wed, 12 Apr 2000 22:29:52 +0200 (MET DST)
=
X-Gnus-Mail-Source: file:/var/spool/mail/sb
Message-ID: <001901bfa4bd$bc6568c0$0e27d8c1@default>
Reply-To: "Espen OEyen" <esoeyen@c2i.net>
From: "Espen OEyen" <esoeyen@c2i.net>
To: "Steinar Bang" <steinar@bang.priv.no>
References: <38e61a57.13531740@news.online.no> <5fpF4.4591$%u.329986@ju=
liett.dax.net> <whzor58zfx.fsf@viffer.metis.no> <000701bfa177$edeee5e0$=
addad9c1@default> <wh66tr4k8m.fsf@viffer.metis.no>
Subject: Re: Da var det gjort
Date: Wed, 12 Apr 2000 22:28:57 +0200
Organization: M=F8ller
MIME-Version: 1.0
Content-Type: text/plain;
	charset=3D"iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
X-MIME-Autoconverted: from quoted-printable to 8bit by metis.no id WAA1=
2278

Re: More on forwarding quoted-printable encoded messages

[Steinar Bang]

>>>>> Steinar Bang <sb@metis.no>:

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:
>> Steinar Bang <sb@metis.no> writes:
>>> I haven't tried it on a message with 8bit characters in the headers,
>>> but when I try forwarding a text/plain; charset=iso-8859-1 message, I
>>> get the following headers if I do C-u on the rfc822 part after doing a
>>> C-d (ie. the message/rfc822 c-t-e, is still q-p, which is disallowed by RFC
>>> 2046, section 5.2.1 (only 7bit, 8bit and binary allowed)):

>> Could you try again with the cvs that will be available in a few
>> minutes?

> I didn't try then (wasn't online), but I tried with a checkout from
> just before 20:00 MET DST tonight.  But it looks the same.

> The original message I'm trying to forward has a c-t-e of 8bit.  I'm
> wondering if things had been different if it had been q-p, but I don't
> know how to force a q-p message in the folders, so I don't know how to
> test this.

I tried that.  If the forwarded message has a c-t-e of base64, and the
message/rfc822 part could be safely said to have a c-t-e of 7bit, the
forwarded message ends up with 8bit and the message/rfc822 ends up
with no q-t-e header.

Note!  What follows is complete messages with all headers interspersed
with comments.

Here's the message I forwarded (it hasn't been sent.  I just forwarded
it from the nndraft:queue mail group):

To: Steinar Bang <sb@metis.no>
Subject: heisann hoppsann!
BCC: sb@metis.no
From: Steinar Bang <sb@metis.no>
Date: 26 Apr 2000 08:04:38 +0200
Message-ID: <whln21e6tl.fsf@viffer.metis.no>
User-Agent: Gnus/5.0805 (Gnus v5.8.5) XEmacs/20.4 (Emerald)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: base64

QuZkIGL4ZCENCg=

Here's the result from C-c C-f:

To: Steinar Bang <sb@metis.no>
Subject: [Steinar Bang <sb@metis.no>] heisann hoppsann!
BCC: sb@metis.no
From: Steinar Bang <sb@metis.no>
Date: 26 Apr 2000 08:04:54 +0200
Message-ID: <whhfcpe6t5.fsf@viffer.metis.no>
User-Agent: Gnus/5.0805 (Gnus v5.8.5) XEmacs/20.4 (Emerald)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="

--=-=-
Hallo!


--=-=-Content-Type: message/rfc822; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

To: Steinar Bang <sb@metis.no>
Subject: heisann hoppsann!
BCC: sb@metis.no
From: Steinar Bang <sb@metis.no>
Date: 26 Apr 2000 08:04:38 +0200
Message-ID: <whln21e6tl.fsf@viffer.metis.no>
User-Agent: Gnus/5.0805 (Gnus v5.8.5) XEmacs/20.4 (Emerald)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1

Bæd bød!

--=-=-=--


For completeness, here's the same message after having been sent, and
having been converted from base64 to 8bit by sendmail:

X-From-Line: sb@metis.no  Wed Apr 26 08:18:05 2000
Return-Path: <sb@metis.no>
Received: from localhost (sb@localhost [127.0.0.1])
	by viffer.metis.no (8.9.3/8.9.3) with ESMTP id IAA11529
	for <sb@localhost>; Wed, 26 Apr 2000 08:18:04 +0200
Received: from tyr.metis.no
	by localhost with IMAP (fetchmail-5.1.0)
	for sb@localhost (single-drop); Wed, 26 Apr 2000 08:18:04 +0200 (MEST)
Received: by metis.no (8.9.1/8.9.1) with ESMTP id IAA04359; Wed, 26 Apr 2000 08:17:36 +0200 (MET DST)
Received: (from sb@localhost)
	by viffer.metis.no (8.9.3/8.9.3) id IAA11513;
	Wed, 26 Apr 2000 08:17:05 +0200
To: Steinar Bang <sb@metis.no>
Subject: Heisann hoppsann!
From: Steinar Bang <sb@metis.no>
Date: 26 Apr 2000 08:17:05 +0200
X-Gnus-Mail-Source: file:/var/spool/mail/sb
Message-ID: <whya61croe.fsf@viffer.metis.no>
User-Agent: Gnus/5.0805 (Gnus v5.8.5) XEmacs/20.4 (Emerald)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by metis.no id IAA04359

Bæd bød!


Forwarding this message results in q-p c-t-e on the message/rfc822
part (which should be 7bit) and no c-t-e on the forwarded message
(should be q-p or base64):

To: Steinar Bang <sb@metis.no>
Subject: [Steinar Bang <sb@metis.no>] Heisann hoppsann!
BCC: sb@metis.no
From: Steinar Bang <sb@metis.no>
Date: 26 Apr 2000 08:19:19 +0200
Message-ID: <whu2gpcrko.fsf@viffer.metis.no>
User-Agent: Gnus/5.0805 (Gnus v5.8.5) XEmacs/20.4 (Emerald)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="

--=-=-
Hei igjen!


--=-=-Content-Type: message/rfc822; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

X-From-Line: sb@metis.no  Wed Apr 26 08:18:05 2000
Return-Path: <sb@metis.no>
Received: from localhost (sb@localhost [127.0.0.1])
	by viffer.metis.no (8.9.3/8.9.3) with ESMTP id IAA11529
	for <sb@localhost>; Wed, 26 Apr 2000 08:18:04 +0200
Received: from tyr.metis.no
	by localhost with IMAP (fetchmail-5.1.0)
	for sb@localhost (single-drop); Wed, 26 Apr 2000 08:18:04 +0200 (MEST)
Received: by metis.no (8.9.1/8.9.1) with ESMTP id IAA04359; Wed, 26 Apr 2000 08:17:36 +0200 (MET DST)
Received: (from sb@localhost)
	by viffer.metis.no (8.9.3/8.9.3) id IAA11513;
	Wed, 26 Apr 2000 08:17:05 +0200
To: Steinar Bang <sb@metis.no>
Subject: Heisann hoppsann!
From: Steinar Bang <sb@metis.no>
Date: 26 Apr 2000 08:17:05 +0200
X-Gnus-Mail-Source: file:/var/spool/mail/sb
Message-ID: <whya61croe.fsf@viffer.metis.no>
User-Agent: Gnus/5.0805 (Gnus v5.8.5) XEmacs/20.4 (Emerald)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from base64 to 8bit by metis.no id IAA04359

Bæd bød!


--=-=-=--

Re: More on forwarding quoted-printable encoded messages

[Shenghuo ZHU]

>>>>> "Steinar" == Steinar Bang <sb@metis.no> writes:

>> The original message I'm trying to forward has a c-t-e of 8bit.  I'm
>> wondering if things had been different if it had been q-p, but I don't 
>> know how to force a q-p message in the folders, so I don't know how to 
>> test this.

Steinar> I tried that.  If the forwarded message has a c-t-e of
Steinar> base64, and the message/rfc822 part could be safely said to
Steinar> have a c-t-e of 7bit, the forwarded message ends up with 8bit
Steinar> and the message/rfc822 ends up with no q-t-e header.

I don't think that the problem is simply the c-t-e of
message/rfc822. In the current version, the message/rfc822 part is
only charset-decoded (gnus-article-decode-hook). When the message is
sent, the part is re-encoded.  I don't think this is a right solution.
The message/rfc822 part should be unchanged or totally
decoded/re-encoded (mml <-> mime). The former solution is not
acceptable to many users, because those users may want to change the
content. In the latter solution, the c-t-e is not necessary at all.

-- 
Shenghuo

Re: More on forwarding quoted-printable encoded messages

[Steinar Bang]

>>>>> Shenghuo ZHU <zsh@cs.rochester.edu>:

> I don't think that the problem is simply the c-t-e of
> message/rfc822. In the current version, the message/rfc822 part is
> only charset-decoded (gnus-article-decode-hook). When the message is
> sent, the part is re-encoded.  I don't think this is a right
> solution.  The message/rfc822 part should be unchanged or totally
> decoded/re-encoded (mml <-> mime). The former solution is not
> acceptable to many users, because those users may want to change the
> content. In the latter solution, the c-t-e is not necessary at all.

According to RFC-2046 section 5.2.1 (covering message/rfc822), last
paragraph, the only legal c-t-encodings for message/rfc822, are 7bit,
8bit, and binary.

The way I see it, this means that the only safe c-t-e to chose when
creating a message/rfc822 part, would be 7bit, which according to
RFC-2046 would require the message itself to be encoded before
inclusion, and with any non-ASCII headers encododed according to
RFC-2047

Here's the last parargraph of section 5.2.1 of
	http://www.ietf.org/rfc/rfc2046.txt

   No encoding other than "7bit", "8bit", or "binary" is permitted for
   the body of a "message/rfc822" entity.  The message header fields are
   always US-ASCII in any case, and data within the body can still be
   encoded, in which case the Content-Transfer-Encoding header field in
   the encapsulated message will reflect this.  Non-US-ASCII text in the
   headers of an encapsulated message can be specified using the
   mechanisms described in RFC 2047.

Re: More on forwarding quoted-printable encoded messages

[Bjørn Mork]

Steinar Bang <sb@metis.no> writes:
> >>>>> Shenghuo ZHU <zsh@cs.rochester.edu>:
> 
> > I don't think that the problem is simply the c-t-e of
> > message/rfc822. In the current version, the message/rfc822 part is
> > only charset-decoded (gnus-article-decode-hook). When the message is
> > sent, the part is re-encoded.  I don't think this is a right
> > solution.  The message/rfc822 part should be unchanged or totally
> > decoded/re-encoded (mml <-> mime). The former solution is not
> > acceptable to many users, because those users may want to change the
> > content. In the latter solution, the c-t-e is not necessary at all.
> 
> According to RFC-2046 section 5.2.1 (covering message/rfc822), last
> paragraph, the only legal c-t-encodings for message/rfc822, are 7bit,
> 8bit, and binary.
> 
> The way I see it, this means that the only safe c-t-e to chose when
> creating a message/rfc822 part, would be 7bit, which according to
> RFC-2046 would require the message itself to be encoded before
> inclusion, and with any non-ASCII headers encododed according to
> RFC-2047

I believe the forwarded message should be unchanged even if the it
violates RFC2046/7 e.g. by using 8bit headers. The message/rfc822 CTE 
would then be 8bit if the original message, including headers, contains 
any 8bit chars, otherwise 7bit. RFC2046 does not require the forwarded 
message to comply with RFCs 2046-49. It even explicitly states that the 
body of a message/rfc822 part does not need to be RFC822-conformant! How 
do you encode the forwarded message if it contains 8bit characters but 
no CT/CTE headers? Isn't it better not to make any charset and encoding 
choice for the final recipient, and therefore forward the message 
untouched?


Bjørn

Re: More on forwarding quoted-printable encoded messages

[Steinar Bang]

>>>>> "Bjørn Mork" <bmork@dod.no>:

> I believe the forwarded message should be unchanged even if the it
> violates RFC2046/7 e.g. by using 8bit headers. The message/rfc822
> CTE would then be 8bit if the original message, including headers,
> contains any 8bit chars, otherwise 7bit. RFC2046 does not require
> the forwarded message to comply with RFCs 2046-49. It even
> explicitly states that the body of a message/rfc822 part does not
> need to be RFC822-conformant! How do you encode the forwarded
> message if it contains 8bit characters but no CT/CTE headers? Isn't
> it better not to make any charset and encoding choice for the final
> recipient, and therefore forward the message untouched?

Well, the fact of the matter is that the current approach (c-t-e q-p
on the message/rfc822 part) breaks when read in Gnus 5.8.x, Netscape,
Outlook98, and OE, if the message you're forwarding contains non
US-ASCII characters.

Complying with RFC-2046 seems to me, like a step towards un-breaking
Gnus forwarding.

I see interoperability with other mail agents for the messages I am
forwarding these days (text/plain; charset=iso-8859-1, c-t-e q-p or
8bit) as more important than correct transfer of hypotethical non-MIME
messages with 8bit characters.

Re: More on forwarding quoted-printable encoded messages

[Shenghuo ZHU]

>>>>> "Bjørn" == Bjørn Mork <bmork@dod.no> writes:

Bjørn> Steinar Bang <sb@metis.no> writes:
>> >>>>> Shenghuo ZHU <zsh@cs.rochester.edu>:
>> 
>> > I don't think that the problem is simply the c-t-e of
>> > message/rfc822. In the current version, the message/rfc822 part is
>> > only charset-decoded (gnus-article-decode-hook). When the message is
>> > sent, the part is re-encoded.  I don't think this is a right
>> > solution.  The message/rfc822 part should be unchanged or totally
>> > decoded/re-encoded (mml <-> mime). The former solution is not
>> > acceptable to many users, because those users may want to change the
>> > content. In the latter solution, the c-t-e is not necessary at all.
>> 
>> According to RFC-2046 section 5.2.1 (covering message/rfc822), last
>> paragraph, the only legal c-t-encodings for message/rfc822, are 7bit,
>> 8bit, and binary.
>> 
>> The way I see it, this means that the only safe c-t-e to chose when
>> creating a message/rfc822 part, would be 7bit, which according to
>> RFC-2046 would require the message itself to be encoded before
>> inclusion, and with any non-ASCII headers encododed according to
>> RFC-2047

Bjørn> I believe the forwarded message should be unchanged even if the it
Bjørn> violates RFC2046/7 e.g. by using 8bit headers. The message/rfc822 CTE 
Bjørn> would then be 8bit if the original message, including headers, contains 
Bjørn> any 8bit chars, otherwise 7bit. RFC2046 does not require the forwarded 
Bjørn> message to comply with RFCs 2046-49. It even explicitly states that the 
Bjørn> body of a message/rfc822 part does not need to be RFC822-conformant! How
Bjørn> do you encode the forwarded message if it contains 8bit characters but 
Bjørn> no CT/CTE headers? Isn't it better not to make any charset and encoding 
Bjørn> choice for the final recipient, and therefore forward the message 
Bjørn> untouched?

I think it is better to let user choose whether to forward a message
untouched or re-encoded.

-- 
Shenghuo

Re: More on forwarding quoted-printable encoded messages

[Roman Belenov]

Shenghuo ZHU <zsh@cs.rochester.edu> writes:

> I think it is better to let user choose whether to forward a message
> untouched or re-encoded.

How will it be presented to user when composing forwarding message in
the former case ?

-- 
 							With regards, Roman.

Re: More on forwarding quoted-printable encoded messages

[Steinar Bang]

>>>>> Shenghuo ZHU <zsh@cs.rochester.edu>:

> I think it is better to let user choose whether to forward a message
> untouched or re-encoded.

I agree.

Re: More on forwarding quoted-printable encoded messages

[Shenghuo ZHU]

>>>>> "Roman" == Roman Belenov <roman@nstl.nnov.ru> writes:

Roman> Shenghuo ZHU <zsh@cs.rochester.edu> writes:
>> I think it is better to let user choose whether to forward a message
>> untouched or re-encoded.

Roman> How will it be presented to user when composing forwarding
Roman> message in the former case ?

In untouched mode, user will see the buffer name which contains the
forwarding message, because the raw forwarding message may contain
8-bit characters, which can not exist in a multibyte buffer.  When the
message is sent, CTE=8bit is used in the header if it is necessary.

-- 
Shenghuo