And the answer is, it's a bug. MailBinding in camel-mail is looking for content of type Multipart, whereas what's coming through is javax.mail.util.SharedByteArrayInputStream.
But that was reasonable, since the JavaMail javadoc says, "The object returned for a 'multipart' content is always a Multipart subclass. For content-types that are unknown to the DataHandler system, an input stream is returned as the content." So that means it looks like the bug is in the JavaMail DataHandler. Researching further... Don On Mon, Jul 4, 2011 at 5:08 PM, Donald Whytock <dwhyt...@gmail.com> wrote: > Hi all... > > I remember seeing posts regarding attachments before...not sure if > this is more of the same... > > When I send email from Gmail I can send either rich-formatting or > plain text. If I send plain text, my message gets through fine, with > a content-type of "text/plain". But if I send it rich-formatting, > Gmail breaks it into two parts: a plain text body and a formatted > body, with UUID-style delimiters in between. The content-type is > "multipart/alternative". > > My consumer on a camel-mail endpoint sees the plaintext message with > no problem. What I receive in the message body from the > multipart/alternative is both bodies plus the delimiters. > > Is this a bug in how camel-mail is supposed to be functioning? Or an > unimplemented feature? I.e. something camel-mail is doing wrong or > something it isn't doing at all? > > Don >
