Un-MIMEified MIME message

Un-MIMEified MIME message

[Shane Holder]

I've got a message that pgnus doesn't seem to want to MIMEify
(buttonize).  From reading the manual it seems that there isn't really 
anything that needs to be done for pgnus to do mime other than hit
M-t, am I correct?

If anyone is interested in the message I'd be happy to forward it, but 
it's an application so I didn't want to post it to the group.

Shane

Re: Un-MIMEified MIME message

[Kai.Grossjohann]

Shane Holder <holder@rsn.hp.com> writes:

  > I've got a message that pgnus doesn't seem to want to MIMEify
  > (buttonize).  From reading the manual it seems that there isn't really 
  > anything that needs to be done for pgnus to do mime other than hit
  > M-t, am I correct?

Hm.  Buttonizing and MIMEification are two different things.  You can
get at the original message with C-u g.  Buttonization means that
buttons are displayed for all parts.  The default behavior is to not
display buttons for inline parts.

kai
-- 
I like _\bb_\bo_\bt_\bh kinds of music.

Re: Un-MIMEified MIME message

[Shane Holder]

>>>>> "Kai" == Kai Grossjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> writes:

  Kai> Shane Holder <holder@rsn.hp.com> writes:
  >> I've got a message that pgnus doesn't seem to want to MIMEify
  >> (buttonize).  From reading the manual it seems that there isn't really 
  >> anything that needs to be done for pgnus to do mime other than hit
  >> M-t, am I correct?

  Kai> Hm.  Buttonizing and MIMEification are two different things.
  Kai> You can get at the original message with C-u g.  Buttonization
  Kai> means that buttons are displayed for all parts.  The default
  Kai> behavior is to not display buttons for inline parts.

I guess I don't understand how buttonization differs from
MIMEification.  I expected buttonization to be Gnus' way of saying
"Hey I understand this and here's a button to show you what I can do
with it." 

Under Gnus 5.x and TM, it would buttonize the attachment but I
couldn't extract it.

Here are the headers with content deleted.  The First Content-Type: is
from the mail header, the rest are in the body.

> Content-Type: multipart/mixed; boundary="openmail-part-1ca8043e-00000001"
> 
> --openmail-part-1ca8043e-00000001
> Date: Tue, 23 Feb 1999 14:29:50 -0500
> Content-Type: message/rfc822
> 
> Subject: FW: the acne game
> MIME-Version: 1.0
> From: <deleted>
> TO: <deleted
> Content-Type: multipart/Mixed; boundary="openmail-part-1ca8043e-00000002"
> 
> 
> --openmail-part-1ca8043e-00000002
> Content-Type: application/octet-stream; name="1.txt"
> Content-Disposition: attachment; filename="1.txt"
> Content-Transfer-Encoding: base64
> 
> UmVjZWl2ZWQ6IGZyb20gYXRscmVsMS5ocC5jb20gKGF0bHJlbDEuaHAuY29tIFsxNS4xMC4x
> NzYuMTBdKSBieSBpMzEyNW9tMy5hdGwuaHAuY29tIHdpdGggRVNNVFAgKDguOC42IChQSE5F
> [...]
> ZW50LVR5cGU6IG11bHRpcGFydC9taXhlZDsKCWJvdW5kYXJ5PSItLS0tXz1fTmV4dFBhcnRf
> MDAwXzAxQkU1RjRBLjUzN0RGRjVDIgo=
> 
> --openmail-part-1ca8043e-00000002
> Content-Type: text/plain;charset="iso-8859-1"
> Content-Disposition: inline; filename="FW:"
> Content-Transfer-Encoding: 7bit
> 
> <stuff deleted>
> 
> --openmail-part-1ca8043e-00000002
> Content-Type: application/octet-stream; name="acne.exe"
> Content-Disposition: attachment; filename="acne.exe"
> Content-Transfer-Encoding: base64
> 
> TVqiAAEAAAAEABEA//8HAAABZUAAAAAAQAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> AAAAAAAAsAAAAOhTAFRoaXMgcHJvZ3JhbSByZXF1aXJlcyBNaWNyb3NvZnQgV2luZG93cy4N
> [...]
> VUhUAAAAAE1VSFQAAAAATVVIVAAAAABNVUhUAAAAAE1VSFQAAAAATVVIVAAAAABNVUhUAAAA
> AD6/CwA=
> 
> --openmail-part-1ca8043e-00000002
> Content-Type: text/plain
> Content-Transfer-Encoding: quoted-printable
> 
> FROM: <deleted>
> TO: <deleted>
> 
> --openmail-part-1ca8043e-00000002
> Content-Type: text/plain
> Content-Transfer-Encoding: quoted-printable
> 
> TO: <deleted>
> 
> --openmail-part-1ca8043e-00000002--
> 
> --openmail-part-1ca8043e-00000001--


When I M-t the message I get one button up at the very top
[1. message/rfc822]. This is coming through HP's Openmail system
interfaced by CC:Mail, so it could be inserting foobar'd headers.  But
I don't speak enough MIME to tell.

Shane

Re: Un-MIMEified MIME message

[Kai.Grossjohann]

Shane Holder <holder@rsn.hp.com> writes:

  > I guess I don't understand how buttonization differs from
  > MIMEification.  I expected buttonization to be Gnus' way of saying
  > "Hey I understand this and here's a button to show you what I can do
  > with it." 

MIMEification means to display a MIME message in a meaningful way.
Buttonization means do MIMEification *plus* add buttons for every
part.

For instance.  Let's say you have a three-part multipart/mixed, and
the first part is text/plain with the contents "first", the second is
text/html with the contents "<b>second</b>", and the third is
text/plain with the contents "third".  Gnus will display text/plain
and text/html inline by default.  Thus, you will see the following:

,-----
| firstsecondthird
`-----

But the "second" will be bold.

If you add buttons (buttonize), you see this:

,-----
| [1 text/plain]
| first
| [2 text/html]
| second
| [3 text/plain]
| third
`-----

Of course, "second" will again be bold and the [...] things will be
buttons.

Do you now see the difference between MIMEified unbuttonized messages
and MIMEified buttonized ones?

kai
-- 
I like _\bb_\bo_\bt_\bh kinds of music.

Re: Un-MIMEified MIME message

[Lars Magne Ingebrigtsen]

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


--=-=-=

Kai.Grossjohann@CS.Uni-Dortmund.DE writes:

> For instance.  Let's say you have a three-part multipart/mixed, and
> the first part is text/plain with the contents "first", the second is
> text/html with the contents "<b>second</b>", and the third is
> text/plain with the contents "third".  Gnus will display text/plain
> and text/html inline by default.  Thus, you will see the following:
> 
> ,-----
> | firstsecondthird
> `-----
> 
> But the "second" will be bold.

Let's try that, just to see whether it works.  :-)


--=-=-=
Content-Type: multipart/mixed; boundary="==-=-="


--==-=-=

first

--==-=-=
Content-Type: text/html

<b>second</b>

--==-=-=

third

--==-=-=


The above parts were produced by:


[-- Attachment #2.1: Type: text/plain, Size: 6 bytes --]

first

[-- Attachment #2.2: Type: text/html, Size: 14 bytes --]

[-- Attachment #2.3: Type: text/plain, Size: 6 bytes --]

third

[-- Attachment #2.4: Type: text/plain, Size: 127 bytes --]



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

--==-=-=--

--=-=-=--

Re: Un-MIMEified MIME message

[Shane Holder]

>>>>> "Lars" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

  Lars> --=-=-=

  Lars> Kai.Grossjohann@CS.Uni-Dortmund.DE writes:

  >> For instance.  Let's say you have a three-part multipart/mixed, and
  >> the first part is text/plain with the contents "first", the second is
  >> text/html with the contents "<b>second</b>", and the third is
  >> text/plain with the contents "third".  Gnus will display text/plain
  >> and text/html inline by default.  Thus, you will see the following:
  >> 
  >> ,-----
  >> | firstsecondthird
  >> `-----
  >> 
  >> But the "second" will be bold.

  Lars> Let's try that, just to see whether it works.  :-)

I don't know about the rest of you but that did funky things for me.

* When I enter the message with <space> in the summary buffer, it
  sends me to the bottom of the message.

* All of the mail headers are displayed.  Not the normal short headers 
  fontified.

* If I hit t gnus-summary-toggle-header I get the short headers but
  the body disappears.

You know, I'm known for having unusual computer problems, but I hope
others are seeing this. ;-)

Shane

Re: Un-MIMEified MIME message

[Lars Magne Ingebrigtsen]

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

Shane Holder <holder@rsn.hp.com> writes:

> You know, I'm known for having unusual computer problems, but I hope
> others are seeing this. ;-)

I think these things are fixed in 0.78, but the MIME I sent out was
destroyed by the Agent.  Let's try it again:


[-- Attachment #2.1: Type: text/plain, Size: 6 bytes --]

first

[-- Attachment #2.2: Type: text/html, Size: 14 bytes --]

[-- Attachment #2.3: Type: text/plain, Size: 6 bytes --]

third

[-- Attachment #2.4: Type: text/plain, Size: 103 bytes --]


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

Re: Un-MIMEified MIME message

[Jack Vinson]

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

Another interesting with hide/show and buttons.

The 3rd and 4th parts of Lars' previous message showed up on the same
line.  

In other words, it looked like this, with a bold *second*.

[-- Attachment #2: Original buffer --]
[-- Type: text/plain, Size: 135 bytes --]

I think these things are fixed in 0.78, but the MIME I sent out was
destroyed by the Agent.  Let's try it again:

first


secondthird


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


I did 'K b' to show all the buttons (5) of Lars' previous message and then
attempted to hide each one in succession.

When I got to the text/html part, the ellipses appeared after the button,
but the text did not hide.  When I clicked the button again, new text
appeared and the old text remained.  Repeating this cycle caused multiple
entries of the same text, over and over.  Here is an example of this after
several iterations:

[-- Attachment #4: Buttonized buffer --]
[-- Type: text/plain, Size: 153 bytes --]

[1. text/plain]...



[2. text/plain]...



[3. text/html]



second

second

second

second

second

second

[4. text/plain]...



[5. text/plain]...



[-- Attachment #5: Type: text/plain, Size: 127 bytes --]



-- 
Jack Vinson <jvinson@chevax.ecs.umass.edu>    http://www.cis.upenn.edu/~vinson/
Zippy: Yow!  We're going to a new disco!

Re: Un-MIMEified MIME message

[Lars Magne Ingebrigtsen]

Jack Vinson <jvinson@chevax.ecs.umass.edu> writes:

> When I got to the text/html part, the ellipses appeared after the button,
> but the text did not hide.  When I clicked the button again, new text
> appeared and the old text remained.  Repeating this cycle caused multiple
> entries of the same text, over and over. 

Hm.  I did get some rather weird results when doing this, but not
exactly what you describe.  But this may be fixed in 0.80.

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

Re: Un-MIMEified MIME message

[Jack Vinson]

>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

LMI> Jack Vinson <jvinson@chevax.ecs.umass.edu> writes:
>> When I got to the text/html part, the ellipses appeared after the button,
>> but the text did not hide.  When I clicked the button again, new text
>> appeared and the old text remained.  Repeating this cycle caused multiple
>> entries of the same text, over and over. 

LMI> Hm.  I did get some rather weird results when doing this, but not
LMI> exactly what you describe.  But this may be fixed in 0.80.

This has not been corrected in 0.80.  I notice it (the problem) even before
I buttonize my buffer.  With the inlined parts, the words "*second*" and
"third" appear on the same line with a bold "*second*", followed by regular
font "third." 

Again, when I repeatedly whack the third button (text/html) it does not get
displayed correctly.

Here is another interesting feature.  If I C-d the article, the new summary
looks like this:
E  [  40: *Lars Magne Ingebrig] <* mixed> Re: Un-MIMEified MIME message
E      [   7: *Lars Magne Ingebrig] <1 text>
E      [  23: *Lars Magne Ingebrig] <2.* mixed>
E          [   0: *Lars Magne Ingebrig] <2.1 text>
E          [   2: *Lars Magne Ingebrig] <2.2 html>
E          [   0: *Lars Magne Ingebrig] <2.3 text>
E          [   4: *Lars Magne Ingebrig] <2.4 text>

Note that parts 1 and 3 have a Zero line count.  

And when I look at the raw article, the text/plain parts have no
Content-Type header.  I take it the default is text/plain when nothing is
specified?


-- 
Jack Vinson <jvinson@chevax.ecs.umass.edu>    http://www.cis.upenn.edu/~vinson/
Zippy: It was a JOKE!!  Get it??  I was receiving messages
 from DAVID LETTERMAN!!  YOW!!

Re: Un-MIMEified MIME message

[James H. Cloos Jr.]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>>>>> "Jack" == Jack Vinson <jvinson@chevax.ecs.umass.edu> writes:

Jack> And when I look at the raw article, the text/plain parts have no
Jack> Content-Type header.  I take it the default is text/plain when
Jack> nothing is specified?

Yes, as per rfc2046:

rfc2046> If no Content-Type field is present [in a body 
rfc2046> part] it is assumed to be "message/rfc822" in
rfc2046> a "multipart/digest" and "text/plain" otherwise.

- -JimC
- -- 
James H. Cloos, Jr.  <http://www.jhcloos.com/cloos/public_key> 1024D/ED7DAEA6 
<cloos@jhcloos.com>     E9E9 F828 61A4 6EA9 0F2B  63E7 997A 9F17 ED7D AEA6
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v0.9.2 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE23vTemXqfF+19rqYRAvghAJ92ZYsONbgAjczpZLpSsqLFH7a4zgCffr8F
tvbpIAw/7Y6DGQaKLERk2hc=
=pYSs
-----END PGP SIGNATURE-----

Re: Un-MIMEified MIME message

[Lars Magne Ingebrigtsen]

Jack Vinson <jvinson@chevax.ecs.umass.edu> writes:

> Again, when I repeatedly whack the third button (text/html) it does not get
> displayed correctly.

Could you see whether this is a problem under XEmacs as well?

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

Re: Un-MIMEified MIME message

[Jack Vinson]

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


This is an old thread.  I still have the message in which there are
problems.

Lars sent out a five-part message which was supposed to be handled
correctly by Gnus.  Unfortunately, there were some funny things with the
text/html part.  Mainly, it looked like there were some missing EOL
characters, so that the text/html was concatenated onto the end of the
text/plain before it.

When I buttonize the message and whack the text/html part, it is not hidden
correctly.  When I whack it again, a copy of that part is added to the
buffer.

Here is an example:

[-- Attachment #2: Plain text --]
[-- Type: text/plain, Size: 6 bytes --]

first

[-- Attachment #3: html text --]
[-- Type: text/html, Size: 38 bytes --]

[-- Attachment #4: More plain text --]
[-- Type: text/plain, Size: 5 bytes --]

third

[-- Attachment #5: Type: text/plain, Size: 255 bytes --]


-- 
Jack Vinson <jvinson@chevax.ecs.umass.edu>    http://www.cis.upenn.edu/~vinson/
Zippy: If a person is FAMOUS in this country, they have to go on the ROAD
 for MONTHS at a time and have their name misspelled on the SIDE
 of a GREYHOUND SCENICRUISER!!

Re: Un-MIMEified MIME message

[Kai.Grossjohann]

Jack Vinson <jvinson@chevax.ecs.umass.edu> writes:

  > Lars sent out a five-part message which was supposed to be handled
  > correctly by Gnus.  Unfortunately, there were some funny things with the
  > text/html part.  Mainly, it looked like there were some missing EOL
  > characters, so that the text/html was concatenated onto the end of the
  > text/plain before it.

It was *supposed* to be that way -- the EOL characters were omitted on
purpose.

With this, you could write a Japanese and a Polish name in one line,
for example.  (To put text/html in there rather than text/plain was
just a test...)

The problem with hiding is a real bug, of course.

And why is there now a button for text/html?  Hm...

kai
-- 
I like _\bb_\bo_\bt_\bh kinds of music.

Re: Un-MIMEified MIME message

[Lars Magne Ingebrigtsen]

Jack Vinson <jvinson@chevax.ecs.umass.edu> writes:

> When I buttonize the message and whack the text/html part, it is not hidden
> correctly.  When I whack it again, a copy of that part is added to the
> buffer.

Yup.  Fix in Pterodactyl Gnus v0.81.

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

Re: Un-MIMEified MIME message

[Hans de Graaff]

Shane Holder <holder@rsn.hp.com> writes:

> * When I enter the message with <space> in the summary buffer, it
>   sends me to the bottom of the message.
> 
> * All of the mail headers are displayed.  Not the normal short headers 
>   fontified.
> 
> * If I hit t gnus-summary-toggle-header I get the short headers but
>   the body disappears.
> 
> You know, I'm known for having unusual computer problems, but I hope
> others are seeing this. ;-)

I saw all of that too. Perhaps this is because we aren't using the
latest version of w3. I recall some discussion on that version being
needed for correct display of HTML stuff.

Hans

Re: Un-MIMEified MIME message

[Kai.Grossjohann]

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

  > Let's try that, just to see whether it works.  :-)

Hm.  The W3 display thing adds newlines at the beginning?  Too bad...

It works with text/enriched!

kai
-- 
I like _\bb_\bo_\bt_\bh kinds of music.

Re: Un-MIMEified MIME message

[Lars Magne Ingebrigtsen]

Kai.Grossjohann@CS.Uni-Dortmund.DE writes:

> Hm.  The W3 display thing adds newlines at the beginning?  Too bad...

It seems to work ok, but it depends on how the MML is...

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

Re: Un-MIMEified MIME message

[Kai.Grossjohann]

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

  > It seems to work ok, but it depends on how the MML is...

Why is it, then, that

  first<!#part type=text/html><b>second</b><!#part>third

is displayed differently than

  first <!#part type=text/enriched><bold>second</bold><!#part>third

with regard to newlines (the former has a line break before second,
the latter doesn't)?

kai
-- 
I like _\bb_\bo_\bt_\bh kinds of music.

Re: Un-MIMEified MIME message

[Lars Magne Ingebrigtsen]

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

Kai.Grossjohann@CS.Uni-Dortmund.DE writes:

> Why is it, then, that
> 
>   first<!#part type=text/html><b>second</b><!#part>third
> 
> is displayed differently than
> 
>   first <!#part type=text/enriched><bold>second</bold><!#part>third

Let's see...


[-- Attachment #2.1: Type: text/plain, Size: 5 bytes --]

first

[-- Attachment #2.2: Type: text/html, Size: 13 bytes --]

[-- Attachment #2.3: Type: text/plain, Size: 22 bytes --]

third

and then

first

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2.4: Type: text/enriched, Size: 13 bytes --]

<b>second</b>

[-- Attachment #2.5: Type: text/plain, Size: 130 bytes --]

third

So how did that go?

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

Re: Un-MIMEified MIME message

[Lars Magne Ingebrigtsen]

Kai.Grossjohann@CS.Uni-Dortmund.DE writes:

>   first<!#part type=text/html><b>second</b><!#part>third

Yes,

(w3-region (point-min) (point-max))

on a buffer containing just

<b>second</b>

will put two newlines at the beginning of the buffer.  William?

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

Re: Un-MIMEified MIME message

[Kai.Grossjohann]

Shane Holder <holder@rsn.hp.com> writes:

  > Here are the headers with content deleted.  The First Content-Type: is
  > from the mail header, the rest are in the body.

The MIME looks okay.  If you hit RET on the button, pgnus should
display that message, which in turn contains another message.

Maybe you need to type `K b' to buttonize, first.  I think
message/rfc822 are displayed inline by default.

kai
-- 
I like _\bb_\bo_\bt_\bh kinds of music.

Re: Un-MIMEified MIME message

[Kai.Grossjohann]

Shane Holder <holder@rsn.hp.com> writes:

  > I get one button that seems to be for the entire message, I believe I
  > should have at least 3 buttons.  One for the entire message (because
  > it's forwarded as a mime attachment) and then 2 more for the internal
  > attachments, 1.txt and acne.exe.

Well, but what happens when you click on the first button?  You should
then see buttons for the internal attachments.

Though maybe you're right and the article buffer mime display thingy
should be recursive.  Hm.

(Feel free to send the msg, my IP connection is 34MBit or so.  Of
course I have to share the bandwidth with the rest of the
university...)

kai
-- 
I like _\bb_\bo_\bt_\bh kinds of music.

Re: Un-MIMEified MIME message

[Lars Magne Ingebrigtsen]

Shane Holder <holder@rsn.hp.com> writes:

> I've got a message that pgnus doesn't seem to want to MIMEify
> (buttonize).  From reading the manual it seems that there isn't really 
> anything that needs to be done for pgnus to do mime other than hit
> M-t, am I correct?

`K b' will add buttons to a MIME message.

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