problematic implementation of getMessageBody

[GoogleCodeExporter]

posit: it's probably safe to assume that mailparser will always return the 
parts list in order. (1, 1.1, 1.2...)

given that, getMessageBody returns the body of the -last- matching part with 
the requested content-type.

this is probably not what most people expect.

even worse, mailparser seems to take a very simple single-part test email i 
have, but in addition to the 1.1, text/plain, it has added a 1.2, with zero 
length body, and also text/plain for no obvious reason (possible bug in 
mailparser? but i'm not an expert on the RFC)

for my own testcase, my single part text-only email, i would have expected 
getMessageBody to return the body.  instead, it returns an empty string because 
part 1.2 is also text/plain, and of length zero.

two possible fixes:

1. have getMessageBody return the first matching part

or

2. ignore any zero length body in the foreach.

for my own use, i did both.

and yes, it is a somewhat fuzzy request, asking for the "message body" from a 
multipart message, but these two changes might help.

Original issue reported on code.google.com by benja...@rqdq.com on 9 Mar 2011 at 9:36

[GoogleCodeExporter]

 In the case where a user sends an email like this:

  Hey, look at this funny picture:

  [image]

  Isn't that duck adorable?

...there will be two text/plain parts which both (arguably, at least) contain 
parts of the message body. I dealt with this by changing getMessageBody() to 
return the concatenation of all matching parts, although I'm not sure if this 
is a reasonable solution. I'm happy to provide a patch if it seems reasonable, 
it basically boils down to changing "$body =" to "$body .=" in getMessageBody().

Original comment by epriest...@epriestley.com on 13 Jun 2011 at 5:07