Thanks,
I never used mtest before, but that nice to have :)
Here's how it looks like from mtest (below); I'm thinking the parser is
expecting something that is not there in the enclosed message (bad
message).
The message contains these parts:
[multipart/mixed]
+-[audio/wave]
+-[message/rfc822]
+-[multipart/mixed]
+-[audio/wav]
+-[message/rfc822]
+-[audio/wav]
It's a chain of forwarded emails.
At least that what I see when saving the email to file from outlook
express.
Can I load/parse a MIME file straight up in Mtest? I could pinpoint what
cause the behavior.
Mtest was compiled from the imap-2007 downloaded about a 3 weeks ago.
PatH
==================== Mtest Trace ======================
* 2 FETCH (UID 6 ENVELOPE ("Tue, 12 Feb 2008 22:05:41 +0000" "FW: My"
(("PatH" NIL "path" "example.com")) (("PatH" NIL "path" "example.com"))
(("PatH" NIL "path" "example.com")) (("PatH" NIL "path"
"example.com")) NIL NIL NIL "MAL.87ed6ea9-3351-412d-a048-c8aac61fc703")
BODY[HEADER.FIELDS (NEWSGROUPS FOLLOWUP-TO REFERENCES)
] {2}
BODYSTRUCTURE (("audio" "wav" ("name" "My.wav") NIL NIL "Base64" 113287
NIL ("inline" ("filename" "My.wav")) NIL NIL)("message" "rfc822" NIL NIL
NIL NIL 113287 NIL) NIL NIL NIL NIL NIL NIL NIL) ("audio" "wav"
("name" "My.wav") NIL NIL "Base64" 113287 NIL ("inline" ("filename"
"My.wav")) NIL NIL) 0 NIL NIL NIL NIL) "mixed" NIL NIL NIL NIL)
INTERNALDATE "12-Feb-2008 22:05:43 +0000" RFC822.SIZE 113287 FLAGS
(\Recent))
%Missing body message envelope
%Missing multipart subtype
%Unknown body disposition: NIL NIL NIL NIL NIL) ("audio" "wav" ("name"
"My.wav") NIL NIL "Base6
%Unknown message property: ("AUDIO"
%Unknown message property: "WAV"
%Unknown message property: ("NAME"
%Unknown message property: "MY.WAV"
%Unknown message property: NIL
%Unknown message property: NIL
%Unknown message property: "BASE64"
%Unknown message property: 113287
%Unknown message property: NIL
%Unknown message property: ("INLINE"
%Unknown message property: ("FILENAME"
%Unknown message property: "MY.WAV"
%Unknown message property: NIL
%Unknown message property: NIL
%Unknown message property: 0
%Unknown message property: NIL
%Unknown message property: NIL
%Unknown message property: NIL
%Unknown message property: NIL
%Unknown message property: "MIXED"
%Unknown message property: NIL
%Unknown message property: NIL
%Unknown message property: NIL
%Unknown message property: NIL
00000007 OK FETCH Completed
1 AUDIO/WAV;name=Message.wav (113287 bytes)
2 MESSAGE/RFC822_MISSING_ENVELOPE (0 lines)
MTest>
========================================================
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Mark Crispin
Sent: Tuesday, February 12, 2008 1:22 PM
To: Patrick Hamel (path)
Cc: imap-uw@u.washington.edu
Subject: Re: [Imap-uw] Handling of enclosed message in multipart
messages.
mail_fetchstructure() (or one of its alternative forms) is most
certainly the correct thing to get the body structure of a message and
run it down.
You certainly should not be playing with any driver settings either.
Have you tried running the mtest tool (bundled with the UW IMAP toolkit)
on the message in question? What does the 'B' command in that tool say
about the bodystructure? Does it show the multipart or does it show a
text part?
Also, note that the proper test for an encapsulated message is *NOT*
body->type == TYPEMESSAGE
but rather is
(body->type == TYPEMESSAGE) && !strcmp (body->subtype,"RFC822")
That is, non-RFC822 subtypes of TYPEMESSAGE should be treated like
TYPETEXT and not as an encapsulated message.
On Tue, 12 Feb 2008, Patrick Hamel (path) wrote:
> Hi,
>
> I'm not sure I'm doing something wrong but just in case, let me bounce
> that off of the experts.
>
> I'm trying to walk all the parts of a multipart message. One of the
> part is a message/rfc822 part which contains a multipart message too.
>
> So the code I have looks a little like this:
>
> BODY *body = null;
> ENVELOPE *env = mail_fetchstructure(stream, msgNo, &body); ...
> and then loop when the type is a multipart message:
>
> PART * curPart = body->nested.part;
> while( curPart ) {
> // dig
> BODY *curBody = curPart->body;
> ... then when the type for the curBody is TYPEMESSAGE
> if( curBoy->type == TYPEMESSAGE ) {
>
> .. we should be able to get to the enclosed body like so:
> MESSAGE *msg = curBody->nested.msg;
> BODY *msgBody = msg->body;
> ... and more stuff to do
> }
> }
>
> That's a bit stylized but you get the general idea.
>
> So in the handling of the TYPEMESSAGE body (msgBody) when the email
> sends an enclosed message which is also a multipart message; instead
> of getting msgBody->type == TYPEMULTIPART, I get TYPETEXT; and the
> various pointers to nested.part, bodies and what not are all null. The
> enclosed mail handled as one plain text element (including email
headers).
>
> Is mail_fetchstructure the wrong thing to use?
> Is this some driver setting I need to configure to get the 'downlevel'
> multipart parsed into the structure?
> Is there a way to get the TYPETEXT data re-parsed; kind of getting a
> ENVELOPE and BODY (maybe?) from the msgBody.content.text.data?
>
> Thanks,
>
> PatH
>
>
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
_______________________________________________
Imap-uw mailing list
Imap-uw@u.washington.edu
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
