MIME Message Problem

MIME Message Problem

[Jake Colman]

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


I am forwarding a sample of a type of email that I get fairly regularly.
When I receive it, it shows up as an "application/octet-stream" attachment and is 
not visible.  If I press 'C-u g' to see the complete content of the
MIME-based message, it tells me that it is base64-encoded and all I see is a
bunch of gibberish (of course).  How can I easily see these attachments?  In
almost all cases the attachment is simply a forwarded email that the sender
wants me to read.

I'm not sure how this email will get posted to the mailing list given that I
am forwarding the problem MIME email as a part of this message.  Hopefully, I 
am not going to screw anything up.

TIA!

...Jake




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

[-- Attachment #2.1.1: Type: text/plain, Size: 48 bytes --]

THIS IS SOOOOOOO HILARIOUS !!!!!!!!!!!!!!!



[-- Attachment #2.1.2: FILE0001.ATT --]
[-- Type: application/octet-stream, Size: 1434 bytes --]

Return-Path: <perry.balagur@SRZ.COM>
Received: from  rly-za01.mx.aol.com (rly-za01.mail.aol.com [172.31.36.97]) by
	air-za05.mail.aol.com (v60.28) with ESMTP; Tue, 14 Sep 1999 16:54:50
	-0400
Received: from  MAIL.SRZ.COM (18.16.15.66.63.in-addr.arpa [63.66.15.18]) by
	rly-za01.mx.aol.com (v60.28) with ESMTP; Tue, 14 Sep 1999 16:54:31
	-0400
Message-Id: <TFSAAQSV@SRZ.COM>
From: perry.balagur@SRZ.COM
Date: Tue, 14 Sep 1999 16:13:42 -0700
To: aje2006@aol.com
Subject: Who's the best?
MIME-version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: quoted-printable
X-Mailer: TFS Secure Messaging /310000000/300003000/300001000/0/310260767/

The NYPD, The FBI, and the CIA are all trying to prove that they are the
best at apprehending criminals. The President decides to give them a test.
He releases a rabbit into a forest and each of them has to catch it.    The =
CIA goes in. They place animal informants throughout the forest.
They question all plant and mineral witnesses. After three months of
extensive investigations they conclude that rabbits do not exist.
The FBI goes in. After two weeks with no leads they burn the forest,
killing everything in it, including the rabbit, and they make no apologies.
The rabbit had it coming.
The NYPD goes in. They come out two hours later with a badly beaten bear.
The bear is yelling: "Okay! Okay! I'm a rabbit! I'm a rabbit!"



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


-- 
Jake Colman                     

Principia Partners LLC                  Phone: (201) 946-0300
Harborside Financial Center               Fax: (201) 946-0320
902 Plaza II                           Beeper: (800) 505-2795
Jersey City, NJ 07311                  E-mail: colman@ppllc.com
                                       E-mail: jcolman@jnc.com
                                          web: http://www.ppllc.com

"Every time I think I've idiot-proofed something someone comes up with a
better idiot"

Re: MIME Message Problem

[Shenghuo ZHU]

>>>>> "Jake" == Jake Colman <colman@ppllc.com> writes:

Jake> I am forwarding a sample of a type of email that I get fairly
Jake> regularly.  When I receive it, it shows up as an
Jake> "application/octet-stream" attachment and is not visible.  If I
Jake> press 'C-u g' to see the complete content of the MIME-based
Jake> message, it tells me that it is base64-encoded and all I see is
Jake> a bunch of gibberish (of course).  How can I easily see these
Jake> attachments?  In almost all cases the attachment is simply a
Jake> forwarded email that the sender wants me to read.

Jake> I'm not sure how this email will get posted to the mailing list
Jake> given that I am forwarding the problem MIME email as a part of
Jake> this message.  Hopefully, I am not going to screw anything up.

Press 'i' on the "application/octet-stream" button.  Though the
attached message is not treated as message/rfc822, you can see the raw
text.

-- 
Shenghuo ZHU

Re: MIME Message Problem

[Jake Colman]

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

>>>>> "Jake" == Jake Colman <colman@ppllc.com> writes:
    Jake> I am forwarding a sample of a type of email that I get fairly
    Jake> regularly.  When I receive it, it shows up as an
    Jake> "application/octet-stream" attachment and is not visible.  If I
    Jake> press 'C-u g' to see the complete content of the MIME-based
    Jake> message, it tells me that it is base64-encoded and all I see is a
    Jake> bunch of gibberish (of course).  How can I easily see these
    Jake> attachments?  In almost all cases the attachment is simply a
    Jake> forwarded email that the sender wants me to read.

    Jake> I'm not sure how this email will get posted to the mailing list
    Jake> given that I am forwarding the problem MIME email as a part of this
    Jake> message.  Hopefully, I am not going to screw anything up.

    ZSH> Press 'i' on the "application/octet-stream" button.  Though the
    ZSH> attached message is not treated as message/rfc822, you can see the
    ZSH> raw text.


But why is this necessary?  Is this the way it us _supposed_ to work?  If
pressing 'i' allows me to see the message, that's great.  I'd just like to
understand what is going on?

Thanx!


-- 
Jake Colman                     

Principia Partners LLC                  Phone: (201) 946-0300
Harborside Financial Center               Fax: (201) 946-0320
902 Plaza II                           Beeper: (800) 505-2795
Jersey City, NJ 07311                  E-mail: colman@ppllc.com
                                       E-mail: jcolman@jnc.com
                                          web: http://www.ppllc.com

"Every time I think I've idiot-proofed something someone comes up with a
better idiot"

Re: MIME Message Problem

[Shenghuo ZHU]

>>>>> "Jake" == Jake Colman <colman@ppllc.com> writes:

Jake> But why is this necessary?  Is this the way it us _supposed_ to
Jake> work?  If pressing 'i' allows me to see the message, that's
Jake> great.  I'd just like to understand what is going on?

Gnus does not display it, because Gnus does not know what the content
of attachment actually is.  Content-type application/octet-stream is
"a catch-all type, this is the most widely abused MIME content-type".

If the sender want to you to read the attachment, message/rfc822,
instead of application/octet-stream, should be used as content-type
just like what Gnus does, but some MUAs use the later.

Pressing 'i' on MIME button forces the attachment show as plain text.
I guess it is the last easy resort.

-- 
Shenghuo ZHU

Re: MIME Message Problem

[David S. Goldberg]

It's necessary because whomever is sending you these messages is using
a client that isn't nice enough to tell everyone what type of
attachment is being sent.  On top of that it's encoding plain text in
base64.  There isn't much else Gnus can do with it other than give you
the button and let you inline it if you think that's appropriate.  If
gnus automatically inlined all base64 encoded application/octet-stream
messages you'd probably be pretty upset with it :-)
-- 
Dave Goldberg
Post: The Mitre Corporation\MS B325\202 Burlington Rd.\Bedford, MA 01730
Phone: 781-271-3887
Email: dsg@mitre.org