Where is the text part?

[jxu22]

I try to run example4 and it said that it will enumerate the text part of the email. However, the output is just plain/text...

But it did not give out the content of the email...and I cannot get that through every API you provide.

How could I get that???

[vincent-richard]

Hello,

Did you modified the source code of the example, and how? What is the contents of the email you tested with?

Vincent

[jxu22]

hey,

It is the example4.cpp.

However, My situation is a little different.

Firstly I connect to my gmail account with vmime API Then I get into one of my mail dir, then I fetch one of the message:

vmime::ref vmime::net::message msg = folder -> getMessage(1); // get the first message in mailbox

vmime::refvmime::message downloadMsg = msg -> getParsedMessage(); // tutorial on vmime.org http://vmime.org

vmime::messageParser mp(downloadMsg); // constrct a messageParser object

vmime::utility::outputStreamAdapter out(std::cout); // declare outputstream

for(int i = 0 ; i < mp.getTextPartCount() ; i ++) {

• vmime::ref<const vmime::textPart> tp = mp.getTextPartAt(i);*
  

• tp -> getText() -> extract(out); // assume all the mail contain text*
  

  }

However, even if there are content in my email, there is nothing on the console.

Could you give me a hint about how to extract the content of the body? Moreover, it seems that I could only get the contain in a containHandler object, but not in a string. Do you provide any API to just return the content of email by string type??

Jinyao Xu

2013/11/11 Vincent Richard [email protected]

Hello,

Did you modified the source code of the example, and how? What is the contents of the email you tested with?

Vincent

¡ª Reply to this email directly or view it on GitHubhttps://github.com/kisli/vmime/issues/58#issuecomment-28230697 .

Ðì¾¢Ò¢ Jinyao Xu

University of Illinois At Urbana Champaign

Computer Science, College of Engineering

Powered By SYSU AIESEC ACMICPC £º£©

[ghost]

Hi @jxu22, not sure if you are still interested in what is going on with the text part extraction, but here is what I have figured out about it. I was running into what I believe is the same issue. This is either caused by Gmail's nonstandard behavior, or by some clause that I don't quite understand in the IMAP specification that allows Gmail to return a nil value where other servers don't.

Here is an illustration using raw IMAP through openssl ( see http://www.skytale.net/blog/archives/23-Manual-IMAP.html ). I have a mail account on AIM and a mail account on Gmail, and I have the sent the same message to each of them ( which happens to have sequence number 8 in each account's inbox ). On each I will just include the commands after I have logged in and selected the inbox.

On the AIM account:

. fetch 8 body
* 8 FETCH (BODY (("TEXT" "PLAIN" ("CHARSET" "ISO-8859-1") NIL NIL "7BIT" 12 1)("TEXT" "HTML" ("CHARSET" "ISO-8859-1") NIL NIL "7BIT" 33 1) "ALTERNATIVE"))
. OK FETCH completed

. fetch 8 body[text]
* 8 FETCH (BODY[TEXT] {242}
--047d7b671d82e38b6d04edd7f29e
Content-Type: text/plain; charset=ISO-8859-1

testing CC

--047d7b671d82e38b6d04edd7f29e
Content-Type: text/html; charset=ISO-8859-1

<div dir="ltr">testing CC</div>

--047d7b671d82e38b6d04edd7f29e--
)
. OK FETCH completed

. fetch 8 body[1]
* 8 FETCH (BODY[1] {12}
testing CC
)
. OK FETCH completed

. fetch 8 body[1.text]
* 8 FETCH (BODY[1.TEXT] {12}
testing CC
)
. OK FETCH completed

However, on the Gmail:

. fetch 8 body
* 8 FETCH (BODY (("TEXT" "PLAIN" ("CHARSET" "ISO-8859-1") NIL NIL "7BIT" 12 1)("TEXT" "HTML" ("CHARSET" "ISO-8859-1") NIL NIL "7BIT" 33 1) "ALTERNATIVE"))
. OK Success

. fetch 8 body[text]
* 8 FETCH (BODY[TEXT] {242}
--047d7b671d82e6587804edd7f241
Content-Type: text/plain; charset=ISO-8859-1

testing CC

--047d7b671d82e6587804edd7f241
Content-Type: text/html; charset=ISO-8859-1

<div dir="ltr">testing CC</div>

--047d7b671d82e6587804edd7f241--
)
. OK Success

. fetch 8 body[1]
* 8 FETCH (BODY[1] {12}
testing CC
)
. OK Success

. fetch 8 body[1.text]
* 8 FETCH (BODY[1.TEXT] NIL)
. OK Success

What is noteworthy here is that the two servers agree except in the case of the last command:

<tag> fetch <seq. num> body[1.text] 

where GMail returns NIL while AIM returns the text content of section 1.

This happens to be the IMAP command that VMime produces when trying to extract the content. I debugged through the source over a month ago looking at this, so I am a bit fuzzy on the specifics, but when trying to figure this same issue out, I tracked it down to IMAPMessage.cpp::extractImpl, lines 300-350ish.

This is where VMime builds the fetch command and sends it off to the server. On lines 345-346 we see

        else if (extractFlags & EXTRACT_BODY)
            command << ".TEXT";

Which is where the part of the fetch command that Gmail doesn't like is added to the command. As a completely bogus workaround, I modified the IMAPMessage.cpp source to check if the store's host is "imap.gmail.com" before constructing a command, and omitting the ".TEXT" if that is the case. So if we were fetching this message part's contents on Gmail, VMime would emit the command

. FETCH 8 BODY[1]

while, if we were fetching the message part on any other IMAP server, VMime would emit

. FETCH 8 BODY[1.TEXT]

Probably wouldn't want a bogus hack like this in the VMime repository, but for my application I need the text content even if I am talking to Gmail.

Now, this is completely bogus, and it really seems like GMail is just being noncompliant ( their IMAP implementation is notoriously noncompliant ).